The event data of EV_EFI_VARIABLE_AUTHORITY may not cover the whole EFI variable

[lcp]

Per TCG Trusted Boot Chain in EDK II:

When UEFI secure boot is enabled, the DxeImageVerificationLib verifies the PE image signature based upon the EFI_SIGNATURE_DATA in the EFI_SIGNATURE_LIST of an image signature database. If an EFI_SIGNATURE_DATA is used to verify the image, then this EFI_SIGNATURE_DATA will be measured with EV_EFI_VARIABLE_AUTHORITY in DxeImageVerificationLib Measurement.c MeasureVariable().

So the EV_EFI_VARIABLE_AUTHORITY events for db or MokList only cover EFI_SIGNATURE_DATA, i.e. the x509 certificate used to verify the EFI image, not the whole variable. In such case, we have to check if the event data is really in the EFI variable and rehash the event data.

[okirch]

Can you attach the -ddd output for one such example event here, please? I'd like to understand what exactly is in this hash.

The problem with just re-hashing the existing data we find in the event log is that it will fail when a new shim is installed with a new signer's certificate, or a new grub with a new SUSE certificate.

I think we could address this case very much like the "Shim" variable event. We can inspect the shim to extract the x509 certificate of the signer, and build the EFI_SIGNATURE_DATA for it. We would have to consult the db to find the signature owner.

[lcp]

pcr-oracle.log

There are 3 affected EFI_VARIABLE_AUTHORITY events.

• db-d719b2cb-3d3a-4596-a3bc-dad00e67656f: This one is from the firmware when verifying shim.efi.
• Shim-605dab50-e046-4300-abb6-3dd810dd8b23: This happened when shim verified grub.efi.
• MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23: I'm using the kernel package from kernel:Stable so the project cert was measured.

[okirch]

Thank you. I have some code, but it's not fully working yet.

I pushed some new code to the main branch that should help me with lifting data from users' systems as test cases. Can you please give this a spin:

./pcr-oracle --from eventlog all --verify current -d --create-testcase /tmp/pcr-oracle.test

Then please create a tarball from /tmp/pcr-oracle.test and send it to me. Thank you!

[okirch]

Hi!
I've extended the code to attempt the following:

• extract the signer's certificate from the next boot service application
• when we encounter a VARIABLE_AUTHORITY event for Shim, we load the shim's vendor certificate and perform a quick check to ensure that the BSA was indeed signed. If that is the case, we generate the synthetic event using the raw DER encoded vendor cert
• for VARIABLE_AUTHORITY events for "db" and "MokListRT", we take a similar approach: loop through the respective certificate DB, and if we find the CA cert that was used to issue the certificate that was used to sign the next BSA, we return the authority record from the DB (which is a SignatureData type per UEFI spec).

None of this is tested properly, because I'm currently not testing on openSUSE. Please give it a spin (and don't forget to send me a testcase as described above).

[lcp]

It's clever to read the CA file directly so that we don't have to fiddle with the shim binary. So far, the "db" and "Shim" events are handled properly in my laptop. The "MokList" event for my kernel is tricky since the kernel file is not in ESP, so there is no BSA event for the kernel path :-\

[okirch]

Who generates the MokList event for the kernel? It looks like it's not the shim, because shim loads grub in your log file.
If it's grub, maybe we can make it add an EFI device path that tells us where to look. Partition uuid and path would be sufficient.

Anyway, this issue is getting rather longish. I'll open another one and close this one.

[okirch]

Let's continue this investigation in issue #14.