GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation/measured_boot.md: fix SRTM/DRTM explanations 

Change-Id: If224dc0cf3c0515dbd18daca544c22275e96b459
Ticket: https://ticket.coreboot.org/issues/426
Co-authored-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This commit is contained in:
Sergii Dmytruk 2022-10-24 15:22:12 +03:00 committed by Martin Roth
parent 13bbb04acd
commit f8311775e6
1 changed files with 69 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
Documentation/security/vboot/measured_boot.md
View File

@ -1,16 +1,52 @@
# Measured Boot # Measured Boot
coreboot measured boot is implemented as Google Verified Boot extension. This Measured boot feature was initially implemented as an extension of Google
means in order to use it, vboot needs to be available for your platform. The Verified Boot. However, the two features were decoupled since then and use of
goal of this implementation is to implement an easy to understand and measured boot no longer requires enabling vboot.
transparent measured boot mechanism.
In most cases TPM eventlog is initialized during bootblock before TPM gets set
up, hence digests are not measured into TPM immediately, but are only cached in
the event log. Later, as part of TPM setup, the cached events are applied onto
TPM device. The behaviour is different if TPM_MEASURED_BOOT_INIT_BOOTBLOCK
kconfig is set, which moves TPM initialization into bootblock.
## SRTM
A measured-based trust chain is one that begins with an initial entity that
takes the first measurement, referred 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.
## IBB/CRTM ## IBB/CRTM
The "Initial Boot Block" or "Core Root of Trust for Measurement" is the first The "Initial Boot Block" (IBB) is a one-time executed code block loaded at the
code block loaded at reset vector and measured by a DRTM solution. reset vector. Under measured boot mode, the IBB measures itself before measuring
In case SRTM mode is active, the IBB measures itself before measuring the next the next code block making it an S-CRTM for the measured boot trust chain, an
code block. In coreboot, cbfs files which are part of the IBB are identified SRTM trust chain. Since the IBB measures itself and executes out of DRAM, it is
by a metadata tag. This makes it possible to have platform specific IBB said to have a "Root of Trust" (RoT) that is rooted in software.
measurements without hardcoding them.
## 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 (also known as Platform Secure 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 (Authenticated Code
Module) 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.
## Known Limitations ## Known Limitations
At the moment measuring IBB dynamically and FMAP partitions are not possible but At the moment measuring IBB dynamically and FMAP partitions are not possible but
@ -19,13 +55,10 @@ will be added later to the implementation.
Also SoCs making use of VBOOT_RETURN_FROM_VERSTAGE are not able to use the Also SoCs making use of VBOOT_RETURN_FROM_VERSTAGE are not able to use the
measured boot extension because of platform constraints. measured boot extension because of platform constraints.
## SRTM Mode
The "Static Root of Trust for Measurement" is the easiest way doing measurements
by measuring code before it is loaded.
### Measurements ### Measurements
SRTM mode measurements are done starting with the IBB as root of trust. To construct the coreboot SRTM trust chain, the CBFS files which are part of the
Only CBFS contents are measured at the moment. IBB, are identified by a metadata tag. This makes it possible to have platform
specific IBB measurements without hard-coding them.
#### CBFS files (stages, blobs) #### CBFS files (stages, blobs)
* CBFS data is measured as raw data before decompression happens. * CBFS data is measured as raw data before decompression happens.
@ -102,14 +135,27 @@ cbfstool coreboot.rom extract -r COREBOOT -n fallback/romstage -U -f /dev/stdout
cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum
``` ```
## DRTM Mode ## DRTM
The "Dynamic Root of Trust for Measurement" is realised by platform features Certain hardware platforms, for example those with Intel TXT or AMD-V, provide
like Intel TXT or Boot Guard. The features provide a way of loading a signed a mechanism to dynamically execute a CRTM, referred to as the "Dynamic
"Authenticated Code Module" aka signed blob. Most of these features are also CRTM" (D-CRTM), at any point and repeatedly during a single power life-cycle of
a "Trusted Execution Environment", e.g. Intel TXT. 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.
DRTM gives you the ability of measuring the IBB from a higher Root of Trust To provide as an authority assertion and for the DRTM trust chain attestations
instead of doing it yourself without any hardware support. 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.
## Platform Configuration Register ## Platform Configuration Register
Normally PCR 0-7 are reserved for firmware usage. In coreboot we use just 4 PCR Normally PCR 0-7 are reserved for firmware usage. In coreboot we use just 4 PCR