Re: Trying to understand change in PCR 4 extension behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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.




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux