go-tpm-tools icon indicating copy to clipboard operation
go-tpm-tools copied to clipboard

Support linux userspace eventlog

Open malt3 opened this issue 9 months ago • 1 comments

Systemd measures into various PCRs from userspace. An up to date list can be found here. Interesting entries are those marked as Userspace.

For some time, those measurements were not logged into any eventlog, making it cumbersome to use new systemd versions with go-tpm-tools since the eventlog would not match up with the actual measurements in the PCRs. However, they recently decided to log measurments to a separate eventlog with a similar but slightly different format to what is used in the UEFI boot phase (different location, json encoded). The implementation can be found here: https://github.com/systemd/systemd/pull/29004

My proposal is that go-tpm-tools could combine the uefi tpm eventlog from /sys/kernel/security/tpm0/binary_bios_measurements with the userspace eventlog in /var/log/systemd/tpm2-measure.log when reading the eventlog.

This would allow parsePCClientEventLog to succeed with newer versions of systemd.

malt3 avatar Sep 15 '23 11:09 malt3

Thanks for bringing this to our attention! This would be a useful thing to have in the library. Unfortunately, I don't think it's as simple as merging the two event logs, since the formats are different. The one at /sys/kernel/security/tpm0/binary_bios_measurements is the old TCG/UEFI firmware event log style, which has a known vuln making parsing error prone: https://github.com/google/go-attestation/blob/master/docs/event-log-disclosure.md. The other is the new canonical event log format (https://github.com/systemd/systemd/pull/29004/files#diff-008aac080c67a048b8a921bec34a69c29a9d38f6129c43b067ea19ac88e3e0b6R4368-R4371). We do support canonical event logs in the cel package, but only the TLV format.

Another thing is that parsePCClientEventLog will need updates to understand the validated systemd event log's events for them to be useful (i.e., writing a parser for the events and introducing a new field to MachineState). Otherwise, the events will be placed in RawEvents and your application will need to interpret them.

I don't think we have bandwidth anytime soon to pick this up, but I would be happy to review any code associated with the systemd format. The high level approach we have taken is to separate the parsing of different event logs and merge the MachineState protos. This does assume the MachineState sub-fields are orthogonal in which PCRs they map to, which they appear to be at the moment. Note we have already used the Attestation.canonical_event_log in our verifier to mean something specific. It probably should have a better name, but you will need to introduce a new field

alexmwu avatar Sep 22 '23 00:09 alexmwu