|
|
The open question was whether the live bootloader mailbox would act on a valid component
load after boot, which would reinitialise firmware in place while the secure OS runs and,
with many signed builds of one component in the corpus, allow a rollback.
It will not. Submitting the exact bytes this boot already loaded, so that acceptance would
change no content and only show the path acts, is refused for three different genuine
components with the same status as a nonsense component identifier. That uniformity is the
point: the status means not permitted in this state rather than bad parameter, so the
mailbox is reachable but state-gated closed, and the rollback case cannot even begin
because the current build is refused.
The harness twice refused to run for components this boot did not load, rather than emit a
row, and those voids are why the table is trustworthy.
The result is kept for the right reason: the difference between surface being absent and
surface being reachable but gated matters, because a future firmware could relax the gate
while the mailbox stays as reachable as it is today.
|
