Conversation
The drivers and apps profile (PCR2) is a verbatim copy of the events in the TCG log rather than a prediction, but measureDriversAndApps stopped copying at the EV_SEPARATOR event and dropped anything measured after it. Some firmware measures vendor-defined events to PCR2 after the separators, as part of the transition to OS-present. AMD AGESA (StrixKrackanPI-FP8, module AmdPspDxeV2StxKrk) measures the TSME status from its ReadyToBoot handler as a 1-byte event with the vendor event type 0x8401 to PCR2, gated on the PSP firmware reporting support for the measurement. On builds where that handler runs after the Tcg2Dxe separators (observed on a Lenovo ThinkPad P14s Gen 6 AMD with BIOS 1.19 and 1.20, with both the discrete TPM and the Pluton fTPM selected), the event lands after the EV_SEPARATOR event. Because the profile omitted the event, the sealed PCR2 value could never match the real PCR value and every boot fell back to the recovery key. Resealing did not help because the same truncated profile was generated each time. The preinstall checks did not detect the problem either, because the log replays correctly and events in the OS-present phase are ignored by the phase tracker. Keep copying PCR2 events after the separator, and reject logs with more than one separator in PCR2. Add a mock log option and a test that exercises a post-separator vendor event. When TSME is disabled the same AGESA code additionally measures the event to PCR7, which the secure boot policy profile predicts rather than copies; that case is not addressed here.
|
Thanks for the additional hardware analysis and validation. This substantially overlaps with #556: its first commit ( The main behavioral difference I see is that this PR copies all subsequent PCR2 events through the end of the log, whereas #556 accepts only vendor-defined PCR2 events before the OS-load boundary. #556 also contains a separate HP-specific PCR7 fix. Would you be able to test #556 against the Lenovo log or hardware? If it covers this case, it may be best to consolidate the PCR2 work while retaining the Lenovo/AGESA evidence and test coverage from this PR. |
|
Closed in favour of #556 |
2 participants
The drivers and apps profile (PCR2) is a verbatim copy of the events in the TCG log rather than a prediction, but measureDriversAndApps stopped copying at the EV_SEPARATOR event and dropped anything measured after it.
Some firmware measures vendor-defined events to PCR2 after the separators, as part of the transition to OS-present. AMD AGESA (StrixKrackanPI-FP8, module AmdPspDxeV2StxKrk) measures the TSME status from its ReadyToBoot handler as a 1-byte event with the vendor event type 0x8401 to PCR2, gated on the PSP firmware reporting support for the measurement. On builds where that handler runs after the Tcg2Dxe separators (observed on a Lenovo ThinkPad P14s Gen 6 AMD with BIOS 1.19 and 1.20, with both the discrete TPM and the Pluton fTPM selected), the event lands after the EV_SEPARATOR event.
Because the profile omitted the event, the sealed PCR2 value could never match the real PCR value and every boot fell back to the recovery key. Resealing did not help because the same truncated profile was generated each time. The preinstall checks did not detect the problem either, because the log replays correctly and events in the OS-present phase are ignored by the phase tracker.
Keep copying PCR2 events after the separator, and reject logs with more than one separator in PCR2. Add a mock log option and a test that exercises a post-separator vendor event.
When TSME is disabled the same AGESA code additionally measures the event to PCR7, which the secure boot policy profile predicts rather than copies; that case is not addressed here.
Fixes #570