TrenchBoot / trenchboot-issues

This repository is to centralize issues and development progress tracking for the TrenchBoot project.
4 stars 1 forks source link

Support for TPM 2.0 event log in Xen #11

Closed BeataZdunczyk closed 1 year ago

BeataZdunczyk commented 1 year ago

Is your feature request related to a problem? Please describe.

Currently, Qubes OS AEM does not support logging of the Dom0 kernel and initial ram disk hashes to the TPM event log due to lack of TPM 2.0 event log support in Xen.

Is your feature request related to a new idea or technology that would benefit the project? Please describe.

This issue is required to enable logging of the Dom0 kernel and initial ram disk hashes to the TPM event log, which could be used for future system attestation.

Describe the solution you'd like

Implement support for the TPM 2.0 event log in Xen to enable logging of the Dom0 kernel and initial ram disk hashes to the TPM event log.

Describe alternatives you've considered

N/A

Additional context

This feature request is part of Phase 2 in TrenchBoot as Anti Evil Maid project, as outlined in the documentation: https://docs.dasharo.com/projects/trenchboot-aem-v2/.

Relevant documentation you've consulted

N/A

krystian-hebel commented 1 year ago

https://github.com/TrenchBoot/trenchboot-issues/issues/10#issuecomment-1597053819 applies here as well.

SergiiDmytruk commented 1 year ago

@krystian-hebel Current spec (p. 24) says:

Supported format of TPM 2.0 event log:
= 0 – Original TXT TPM 2.0 Event Log
= 1 – “TCG PC Client Platform. EFI Protocol Specification” compatible Event Log
Always forced to “1”

And I saw an older revision with custom Microsoft's TPM2.0 log (a log per hash type as I understood). It's dated 2016, so old log can still be found in the wild and thus the code should support both?

krystian-hebel commented 1 year ago

I haven't managed to find that specification on any "official" source, and I also haven't seen TrEE being used anywhere. The way I understand it, there is only one log, with algo described in the first entry, and all other entries are basically TPM1.2 format but with different hash sizes.

On one hand, I want to say we can forget about TrEE and assume EFI (aka agile) format. On the other hand, in such case we would have to at least check the signature (FRMT ID EVENT00 vs. Spec ID Event03), but this check would have to be performed very early, before we have console, so we can't notify user about any error at that point. All in all, I think supporting both may be easier than passing the information about deprecated format throughout the boot. We can always check this later, when console is available, and print a warning then.

dpsmith commented 1 year ago

The "Original TXT TPM 2.0 Event Log" was circa 2014/2015 and was in competition with MS TrEE. UEFI TPM log format is direct decedent of TrEE while Original TXT TPM 2.0 Event Log was a log format that was more reminiscent TXT's TPM 1.2 Event Log format. The history is a bit fuzz, but it evolved from the fact that HP bungled the first attempt at TPM2.0 spec and MS went off wrote the code for how they thought a TPM2 should work and then reversed engineered a spec for it. This was then submitted to TCG as an alternative and became the spec. Basically this split carried through in logging until UEFI adopted TrEE and forcing TCG to adopt as well. Details are probably off but that is rough understanding I have from watching it all play out externally. Here is another source on the drama, https://twobit.org/2015/11/08/tree-vs-tcg/

SergiiDmytruk commented 1 year ago

I haven't managed to find that specification on any "official" source, and I also haven't seen TrEE being used anywhere.

That's probably because all SINIT binaries are newer than 2017 and they dropped TrEE from specification in May 2017. Which is why it might not be necessary.

The way I understand it, there is only one log, with algo described in the first entry, and all other entries are basically TPM1.2 format but with different hash sizes.

There are also HEAP_EVENT_LOG_DESCR structs that point to location of logs.

Anyway, TCG format will be there for sure, so I'll start with it and can try adding TrEE later. The issue with TrEE is that there might be no way to test the implementation in which case adding the code for it is somewhat weird.

krystian-hebel commented 1 year ago

Actually, the log format is specified as part of MLE header, is it not? EFI format should be chosen by https://github.com/TrenchBoot/xen/blob/aem/xen/arch/x86/boot/head.S#L129, and if ACM doesn't support it, it should fail before Xen is even started. Single bit flag doesn't allow for multiple implementations, so I think other formats won't ever be needed.

SergiiDmytruk commented 1 year ago

I think you're right, thanks. The comment in an older revision about SINIT supporting only one log format made me think MLE needs to handle it somehow.

SergiiDmytruk commented 1 year ago

PR: https://github.com/TrenchBoot/xen/pull/4

krystian-hebel commented 1 year ago

Logs from test: aem.log

I've manually parsed the event log and used functions from util.sh to validate the correctness of PCR values against log entries for both algorithms. I also checked digests of kernel and initramfs with sha{1,256}sum to test if implemented hash functions return the same values, they are also correct.