Attention is currently required from: Michał Żygowski, Maciej Pijanowski, Krystian Hebel.
Hello Michał Żygowski, Maciej Pijanowski, Krystian Hebel,
I'd like you to do a code review. Please visit
https://review.coreboot.org/c/coreboot/+/68751
to review the following change.
Change subject: [WIP] Documentation/measured_boot.md: fix SRTM/DRTM explanations ......................................................................
[WIP] Documentation/measured_boot.md: fix SRTM/DRTM explanations
Change-Id: If224dc0cf3c0515dbd18daca544c22275e96b459 Ticket: https://ticket.coreboot.org/issues/426 Signed-off-by: Sergii Dmytruk sergii.dmytruk@3mdeb.com --- M Documentation/security/vboot/measured_boot.md 1 file changed, 33 insertions(+), 14 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/51/68751/1
diff --git a/Documentation/security/vboot/measured_boot.md b/Documentation/security/vboot/measured_boot.md index adfae46..8601bcc 100644 --- a/Documentation/security/vboot/measured_boot.md +++ b/Documentation/security/vboot/measured_boot.md @@ -6,8 +6,8 @@
## IBB/CRTM The "Initial Boot Block" or "Core Root of Trust for Measurement" is the first -code block loaded at reset vector and measured by a DRTM solution. -In case SRTM mode is active, the IBB measures itself before measuring the next +code block loaded at reset vector. +In case SRTM is active, the IBB measures itself before measuring the next code block. In coreboot, 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 hardcoding them. @@ -19,12 +19,19 @@ Also SoCs making use of VBOOT_RETURN_FROM_VERSTAGE are not able to use the 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. +## SRTM +The "Static Root of Trust for Measurement" start with boot process after +platform shutdown or restart. It first establishes the root of trust by +measuring bootblock, then the chain of trust is continued by each stage adding +measurements of its successor before passing control to it. + +The idea is to log everything that has been run up until now and if everything +is of known origin and wasn't tempered with, assume the environment was not +compromised. For this to work no stage should escape being measured or change +in unpredictable way after the measurement while still in use.
### Measurements -SRTM mode measurements are done starting with the IBB as root of trust. +SRTM measurements are done starting with the IBB as root of trust. Only CBFS contents are measured at the moment.
#### CBFS files (stages, blobs) @@ -102,14 +109,15 @@ cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum ```
-## DRTM Mode -The "Dynamic Root of Trust for Measurement" is realised by platform features -like Intel TXT or Boot Guard. The features provide a way of loading a signed -"Authenticated Code Module" aka signed blob. Most of these features are also -a "Trusted Execution Environment", e.g. Intel TXT. - -DRTM gives you the ability of measuring the IBB from a higher Root of Trust -instead of doing it yourself without any hardware support. +## DRTM +The "Dynamic Root of Trust for Measurement" avoids the need to verify +everything that happened since boot by relying on hardware means like Intel +TXT or Boot Guard. Instead of starting the chain at boot and building from +there, DRTM ensures trust by isolating measured code from anything that can +modify. This is done by starting DRTM early in a boot process when all +hardware is in a well known state. Once DRTM is up, it remains resident in +memory and can be interacted with through an API when a safe computation +environment is necessary.
## Platform Configuration Register Normally PCR 0-7 are reserved for firmware usage. In coreboot we use just 4 PCR