improvements on the direct boot using UKI #299
Conversation
hector-cao
changed the title
Thanks for the feedback that greatly improved the instructions and script |
README.md
Outdated
| @@ -593,7 +593,8 @@ you proceed to [step 4](#verify-itts-client-version). | |||
|
|
|||
| One of the key components remote attestation is based on is the runtime measurement values (stored in RTMRs | |||
| registers for each TD by the TDX module). These RTMR values are computed from the digests of the entries of | |||
| the TD boot event log. | |||
| the TD boot event log. During the system's boot, each event's digest (SHA384) is extended (appended) to the | |||
There was a problem hiding this comment.
If you're using "appended" to clarify the meaning of "extended", maybe we should just go with "appended" unless "extended" is baked into the language of this component
There was a problem hiding this comment.
the CC terminology uses extended for this operation, i personally did not find it intuitive so try to clarify for people who have the same feeling, but if we have to keep one, it will be extended
guest-tools/direct-boot/boot_uki.sh
Outdated
| @@ -46,15 +46,13 @@ EOM | |||
|
|
|||
| cleanup() { | |||
| echo "cleanup ..." | |||
There was a problem hiding this comment.
If you're deleting the functional part of the cleanup, is there a reason you're keeping the function that just echoes?
There was a problem hiding this comment.
thanks, i will remove it
README.md
Outdated
| registers for each TD by the TDX module). These RTMR values are computed from the digests of the entries of | ||
| the TD boot event log. During the system's boot, each event's digest (SHA384) is extended (appended) to the | ||
| current value of the associated RTMR. The resulting value's digest becomes the new value of the RTMR. | ||
| One of the key components remote attestation is the runtime measurement values (stored in RTMRs |
There was a problem hiding this comment.
Add "of" after "componenets"
There was a problem hiding this comment.
"One of" implies a singular subject, but "values" is plural. Might be better to just flip the sentence around and say something like, "Runtime measurement values (paren contents) are key components of remote attestation."
README.md
Outdated
| current value of the associated RTMR. The resulting value's digest becomes the new value of the RTMR. | ||
| One of the key components remote attestation is the runtime measurement values (stored in RTMRs | ||
| registers for each TD by the TDX module). During the system boot, each component of the boot process (binary or conf) | ||
| is measured into a digest. This digest value is extended (appended) to the RTMR's current value. The digest of the result value |
There was a problem hiding this comment.
Same thing with appended/extended.
Also, I'm not sure what is meant by "measured into a digest". I think what you're meaning here is that each component of the boot process becomes input for the digest/hash function?
There was a problem hiding this comment.
digest is the value from the hash function that is applied to data that needs to be measured
|
Hi Hector, I've been reviewing the TPM measurement sequence during direct boot and noticed a potential discrepancy that could have security implications. I'm seeing conflicting behavior between how OVMF and the EFI handle measurements for RTMR and vTPM. I just wondered if you have checked the event log of vTPM and RTMR on a TDX CVM using an image that supports the direct boot. OVMF (https://github.com/tianocore/edk2/blob/62de957185d71feb9c4d09f4eddcdac1980632fb/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c#L478) attempts to measure into RTMR first and skips vTPM if the RTMR measurement succeeds. On the other hand, the EFI/libstub, as implemented in the Linux kernel patches (https://patches.linaro.org/project/linux-efi/list/?series=236617), prioritizes measurement into vTPM and only proceeds to RTMR if the vTPM measurement fails. This conflicting approach results in an incomplete TPM and RTMR event log on systems using direct boot. Because either OVMF or EFI skips its part of the measurement, neither RTMR nor vTPM has a complete log. This incomplete log is a security concern as it undermines the integrity and verifiability of the boot process. |
|
(the TCG vs CC measurement protocol topic could be a separate issue)
I think the general consensus still is that only one measurement protocol is available at a time. |
Yes, I agree. I just wanted to say the direct boot doesn't work for TDX CVMs.
The firmware should enforce that only one of the protocol is used. The current combination of OVMF and EFI/libstub has a security issue. The boot chain software should measure into both to avoid the security issue such as https://github.com/google/security-research/blob/master/pocs/bios/tpm-carte-blanche/writeup.md |
the improvements are results of the user's feedback on the closed MR : #296