|
|
version enforcement
An earlier pass called this blocked for want of an older build of this component for this
chip, which was wrong: the container the part loads is published and historical versions
are public, so two older vendor-signed builds for this exact chip were obtained.
The older signed build boots and runs. After a full cold power cycle, with the injected
bytes the only copy of that component supplied, the secure OS comes up and an application
both loads and invokes successfully, and application service is provided by that component,
so the injected build is what executes. A positive control re-injecting the running bytes
also boots, so the injection mechanism is sound.
Two objections are closed by measurement rather than argument, because the first version of
this test proved nothing: a resident copy from a previous boot could have been servicing
requests, since the driver-level reset does not clear processor state, so the test was
redone from cold; and the load might have been refused with the secure OS booting anyway,
which the working application service rules out.
A register that cannot answer the question is also recorded: it reports the secure OS
version while only the driver component was substituted, and an earlier draft treated it
first as confirmation and then as refutation, being wrong both times.
Signature enforcement is intact but version enforcement is absent, so any memory-safety
defect fixed between an old build and the current one becomes reachable again by choosing
the old build. This is a route to reachable corruption rather than corruption itself, and
whether it yields one depends on a security fix existing in that window.
|
