Attention is currently required from: Michał Żygowski, Maciej Pijanowski, Krystian Hebel, Sergii Dmytruk.
6 comments:
Patchset:
Apologies for providing entire rewrites, but I think it is important to get this precise to help people correctly understand how these constructs are supposed to work.
File Documentation/security/vboot/measured_boot.md:
Patch Set #1, Line 8: The "Initial Boot Block" or "Core Root of Trust for Measurement" is the first
I would recommend the follow rewrite of the paragraph.
The "Initial Boot Block" (IBB) is a one-time executed code block loaded at the reset vector. Under measured boot mode, the IBB measures itself before measuring the next code block making it an S-CRTM for the measured boot trust chain, an SRTM trust chain. Since the IBB measures itself and executes out of DRAM, it is said to have a "Root of Trust" (RoT) that is rooted in software.
I would recommend adding this section here,
## S-CRTM Hardening
To address attacks that took advantage of the IBB being self-referential with both the "Root of Trust for Verification" (RTV) and "Root of Trust for Measurement" (RTM )being rooted in software, hardening was implemented by CPU manufactures. This was accomplished by introducing RoT, typically an RTV, to an external entity provided by the manufacture that could be validated by the CPU at boot. Examples of this are Intel's BootGuard and AMD's Hardware Validated Boot. These solutions work by having the IBB invoke the manufacture provided RoT as early as possible, for which the CPU has already validated or validates when invoked. The RoT will then validate the IBB, thus moving the root for the respective trust chain, typically the verification trust chain, into hardware.
It should be noted that when Intel BootGuard was originally designed, it provided a measurement mode that resulted in the ACM becoming the S-CRTM for the SRTM trust chain. Unfortunately, this was never deployed and thus relying on "Root of Trust for Verification" (RTV) signature check as the only assertion rooted in hardware. The result is that the IBB as a S-CRTM continues to be self-referential and rooted in software, with its exposure being the gap between the return from the ACM and when the IBB measure itself.
Patch Set #1, Line 22: ## SRTM
I would recommend moving this up before IBB section, and here is my suggestion for wording,
A measured-based trust chain is one that begins with an initial entity that takes the first measurement, referrd to as the "Core Root of Trust for Measurement" (CRTM), before control is granted to the measured entity. This process of measurement and then passing control is referred to as a transitive trust. When the CRTM can only ever be executed once during the power life-cycle of the system, it is referred to as a "Static CRTM" (S-CRTM). Thus the trust chain constructed from the S-CRTM is referred to as the Static Root of Trust for Measurement (SRTM) trust chain. The theory is that as long as a proper transitive trust is conducted as more code is allowed to execute, a trustworthy record showing the provenance of the executing system may be provided to establish the trustworthiness of the system.
Patch Set #1, Line 34: SRTM measurements are done starting with the IBB as root of trust.
Suggested rewording,
To construct the coreboot SRTM trust chain, the cbfs files which are part of the IBB, are identified by a metadata tag. This makes it possible to have platform specific IBB measurements without hard-coding them.
Patch Set #1, Line 112: ## DRTM
Recommend rewrite,
Certain hardware platforms, for example those with Intel TXT or AMD-V, provide a mechanism to dynamically execute a CRTM, referred to as the "Dynamic CRTM" (D-CRTM), at any point and repeatedly during a single power life-cycle of a system. The trust chain constructed by this D-CRTM is referred to as the "Dynamic Root of Trust for Measurement" (DRTM) trust chain. On platforms with Intel TXT and AMD-V, the D-CRTM is the CPU itself, which is the reason for these capabilities being referred to as having a "Root of Trust" (RoT) rooted in hardware.
To provide as an authority assertion and for the DRTM trust chain attestations to co-exist with the SRTM trust chain, the TPM provides localities, localities 1 - 4, which restrict access to a subset of the Platform Configuration Registers (PCR), specifically the DRTM PCRs 17 - 22. The mechanism to assert authority for access to these localities is platform specific, though the intention was for it to be a hardware mechanism. On Intel x86 platforms this is controlled through communication between the CPU and the PCH to determine if the "Dynamic Launch" instruction, GETSEC[SENTER], was executed and that the CPU is in SMX mode. For AMD x86 platforms, this controlled with the APU with a similar enforcement that the "Dynamic Launch" instruction, SKINIT, was executed.
To view, visit change 68751. To unsubscribe, or for help writing mail filters, visit settings.