TCG_HashLogExtendEvent Fails on Lenovo x3550 M5 Server

[geedo0]

What I'm trying to do is install TrustedGRUB2 on a Lenovo x3550 M5 server to boot into a CentOS installation on disk. Without any changes, TrustedGRUB2 will successfully measure core.img and diskboot.img. After that it will try to load the GRUB modules which fail by being stuck inside grub_bios_interrupt for TCG_HashLogExtendEvent. To clarify, this means that if I print a message before and after grub_bios_interrupt inside grub_TPM_int1A_hashLogExtendEvent the message after is not printed and GRUB does not abort. I can also provide a video of the console if that helps.

I noticed that for earlier measurements (which work) you use TCG_CompactHashLogExtendEvent. If I modified the source for grub_TPM_int1A_hashLogExtendEvent to use this interrupt instead everything suddenly starts to work. My suspicion is that there's a bug inside Lenovo's implementation of this interrupt, but I've pretty much hit a wall in trying to debug this further.

Have you ever run into any similar issues or have any ideas on how to proceed?

BIOS Information: UEFI 2.10 Build TBE124M

# tpm_version
  TPM 1.2 Version Info:
  Chip Version:        1.2.5.81
  Spec Level:          2
  Errata Revision:     3
  TPM Vendor ID:       WEC
  Vendor Specific data: 0000
  TPM Version:         01010000
  Manufacturer Info:   57454300

Some more information about my build:

• Checkout of version 1.4.0
• Configure with --enable_boot_time and i386-pc
• Added a print statement to the boot time logging function
• Enabled the TGRUB_DEBUG
• Added debug=all to grub.cfg

[johnwallace123]

We are also seeing the same issue with an HP EliteDesk 705 G2, and this appears to be a dupe of #45. I've noticed that if I change the "grub_fatal" in the grub_TPM_int1A_hashLogExtendEvent to a "grub_printf" and enable debugging that the PCRs are being updated correctly (though I can't boot to completion).

With changing to the TCG_CompactLogHashExtendEvent, do you still get the hash order in the ASCII log (/sys/kernel/security/tpm0/ascii_bios_measurements)?

[geedo0]

I saw that issue, but I think our problem is a separate bug in the BIOS. With our Lenovo, server we don't even get an error status code back (or anything) from the BIOS. In turn, this means we don't even get to the grub_fatal call. I'll double check the hash order when I get a chance to log into the machine. Based on reading the documentation/code I believe the only difference should be that with TCG_CompactHashLogExtendEvent, you lose any string descriptors associated with the event.

[johnwallace123]

Our issues might actually be similar. When avoiding the abort, there is a point at which the hashLogExtendEvent hangs.

On the plus side, the resolution to #11 always gives the string "IPL", so if the string changes to "CompactHash", we've really not lost anything. Do you have a patch that fixes the issue for you?

[neusdan]

I can't remember anymore why I have used TCG_HashLogExtendEvent for the later measurements and not TCG_CompactHashLogExtendEvent for all.

I think it's a good idea to change this because it seems less error prone.

Regarding the string descriptors: on my system they were not printed in sys/kernel/security/tpm0/ascii_bios_measurements

So is this even useful? Is there a way to print them?

[geedo0]

That's great to hear and I agree with you that the TCG_CompactHashLogExtendEvent is less likely to fail vendor side. For what it's worth we also found section 5.2 here which explicitly says to avoid TCG_HashLogExtendEvent on ThinkPads so this idea isn't new.

For our use case, we're only looking at the final PCR values. I didn't even realize these string descriptors and hash logs existed until I dove into this. I can upload my patch as a PR if you like, it's pretty straightforward and works for me.

[neusdan]

yeah please open a PR, thanks!

[securitykernel]

Unfortunately, this project is deprecated and no longer maintained. I will be closing this issue.