[systemd-devel] Trying to understand change in PCR 4 extension behavior
Andrei Borzenkov
arvidjaar at gmail.com
Fri Dec 30 14:31:48 UTC 2022
On 29.12.2022 23:35, Kyle Rose wrote:
> Thanks, Andrei. (And apologies for the delay in being able to check
> this out.) This is very helpful.
>
> Do you know what the reasoning is behind re-extending PCR 4 with a
> kernel measurement here? Would it not have already been measured as
> part of the EFI blob and incorporated into PCR 4 by the firmware
> before the stub was launched?
>
It is not systemd. The difference between v247 and v252 is in how kernel
is started. v247 called into linux kernel directly while v252 goes via
LoadImage protocol which calls into firmware. So it could be your
firmware logging loaded image.
> For context, the previous behavior was ideal for purposes of
> predicting future PCR measurements because all of the necessary
> information could be derived directly from the TPM event log; with the
You still gets all necessary information from TPM even log, not?
> current behavior, predictions will have to replicate (and maintain
> parity with) the EFI stub's behavior for extending PCR 4 because that
> information is no longer all available within the TPM event log.
>
I am not sure I understand. You yourself said that this event is visible
in TPM event log.
> Thanks,
> Kyle
>
> On Mon, Dec 19, 2022 at 1:36 PM Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>>
>> On 14.12.2022 20:28, Kyle Rose wrote:
>> ...
>>
>>>
>>> However, in v252, the corresponding event occurs earlier in the log
>>> and (after some measurements extending PCR 11) is followed by another
>>> BSA event extending PCR 4 with a DevicePath I can't parse from a call
>>> I can't seem to find in the systemd source code:
>>>
>>> - EventNum: 34
>>> PCRIndex: 4
>>> EventType: EV_EFI_BOOT_SERVICES_APPLICATION
>>> DigestCount: 2
>>> Digests:
>>> - AlgorithmId: sha1
>>> Digest: "9a3c68bb105e4c4e70cbc3375bd45d616e220586"
>>> - AlgorithmId: sha256
>>> Digest: "36e49f2a0c246db5836b85319e7b2ae04690aca40227895902870a54a054c78b"
>>> EventSize: 56
>>> Event:
>>> ImageLocationInMemory: 0xb7c36000
>>> ImageLengthInMemory: 7793888
>>> ImageLinkTimeAddress: 0x1000000
>>> LengthOfDevicePath: 24
>>> DevicePath: '04031400f8d1c555cd04b5468a20e56cbb3052d07fff0400'
>>>
>>> Can someone help me decode this so I can figure out where this event
>>> originates, or (if this event is well-known to the folks working on
>>> the trusted computing portion of systemd) tell me where this extension
>>> is triggered in the source code? That will at least help me find and
>>> hopefully understand the relevant change.
>>>
>>
>> This is media device path type with vendor subtype, vendor GUID is
>> STUB_PAYLOAD_GUID defined and used in src/boot/efi/linux.c.
More information about the systemd-devel
mailing list