preinstall: Add explicit checks for empty PCR banks #347
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Whilst this has no consequence for FDE because we seal against a good
bank, it breaks measured boot as required by remote verifiers, as an
empty PCR bank provides a means for an adversary to spoof any host
platform of their choosing.
We reject systems with empty PCR banks by default, but with an opt-in to
permit it. Permitting it is fine for now, but when we get to the point of a
fully verified and attestable runtime in the future, this will not be permitted.
We will need to take some action here, such as capping PCRs 0-7 with an
EV_SEPARATOR
type event that indicates an error occurred in those banks.Whilst an empty PCR bank is considered a firmware bug and we shouldn't be
seeing it on newer devices, it's not that uncommon to see this on devices from
the era when TPM2 devices started introducing SHA384 before the firmware
was ready to use it. We may want to see if we can design a scheme where we
can provide proof that a PCR bank was populated by the firmware and not by
an adversary.