-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Measured Boot: TPM2 event log does not match actual value of PCR-2 #455
Comments
That's true. Currently the Event log exposed to OS contains onyl the UEFIPayload measurement events. coreboot events are stored separately and can be accessed with cbmem utility. That affects all Dasharo boards. Thank you for submitting the issue. |
@frederictobiasc @miczyg1 I think this is a serious issue. We have to fix this, at least for upcoming MSI hardware. In the case of customers platforms, we have to ask if they want such support. |
Yes it is, I recall working on it a few years ago (back when I was playing with UEFI Payload on OptiPlex even before Dasharo) to record the coreboot measurements in TCG format in TcgPei module, however, given that we have improved the event logging in coreboot to use TCG formats, it will be much simpler to do today... |
In the current scenario coreboot uses its own event log format. This header shows how current the TPM event log looks like in coreboot: https://github.com/coreboot/coreboot/blob/master/src/commonlib/include/commonlib/tpm_log_serialized.h One has to modify EDK2 SecurityPkg/Tcg/Tcg2Pei and SecurityPkg/Tcg/TcgPei to parse these entries and create the event log entries for those measurements. THere is one caveat though. Each TCG compliant log should start with an SpecID event with CSRTM version. In our case we have no such event. The very first measurement are VBOOT boot mode in PCR0 and GBB HWID in PCR1 typically. We would like to use GBB HWID for SpecID event but the SpecID event PCR should be PCR0. coreboot also has a function that initializes CRTM which could be an ideal SpecID event. We just have to make sure the tspi_init_crtm function in coreboot is called before the first measurements done in src/security/vboot/vboot_logic.c (so before extend_pcrs is called). That way we will have a nice SpecID event candidate. Although we would have to change the TPM_CRTM_PCR to be 0. This scenario requires the most work and probably shouldn't be pursued due to the patches with TCG standard log are already merged (see second scenario below). Second scenario is that coreboot uses the TCG standard log introduced in patches: https://review.coreboot.org/q/topic:%22tpm-std-logs%22 In that case, the logs stored under cbmem IDs:
should be simply copied over in EDK2 SecurityPkg/Tcg/Tcg2Pei and SecurityPkg/Tcg/TcgPei before any new events are measured and gEfiSecurityPkgTokenSpaceGuid.PcdTpm2ScrtmPolicy and gEfiSecurityPkgTokenSpaceGuid.PcdTpmScrtmPolicy should be set to zero. The code must detect which log is used and act accordingly. |
How about making TCG format the default one if EDK2 is used as a payload? |
Yes, it has been on my mind as well |
The following PRs should resolve this issue: |
Dasharo version
v1.0.19 - shipped with the device
Dasharo variant
protectli VP4650
Affected component(s) or functionality
TPM2 event log (exposed in Linux at
/sys/kernel/security/tpm0/binary_bios_measurements
)Brief summary
The PCR-2 value deduced from the TPM2 event log (exposed on Linux at
/sys/kernel/security/tpm0/binary_bios_measurements
) does not match the actual value of PCR-2.How reproducible
1
How to reproduce
Steps to reproduce the behavior:
sudo tpm2_pcrread sha256:2
tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements
Expected behavior
The current value of PCR-2 matches with the value of PCR-2 deduced from the event log.
Actual behavior
The current value of PCR-2 differs from the value of PCR-2 deduced from the event log.
Additional context
binary_bios_measurements.log
pcrread.log
cbmem-tcpa-log.log
The text was updated successfully, but these errors were encountered: