On Fri, Jun 16, 2017 at 03:51:38PM +0200, Javier Martinez Canillas wrote: > The TCG EFI Protocol Specification (rev 00.13, March 2016) mentions that the > tdEFI_TCG2_BOOT_SERVICE_CAPABILITY StructureVersion Major and Minor should > be checked to determine the EFI_TCG2_BOOT_SERVICE_CAPABILITY struct version. > > In fact, shim checks for this and instead use tdTREE_BOOT_SERVICE_CAPABILITY > if Major == 1 && Minor == 0. The EFI firmware on my Lenovo X1 Carbon reports > these values for the FW TPM2.0 so I first was expecting the code to fail. But > it works and I now see that the structures layout are equal so doesn't matter. > > Do you think that we should be more strict on this? Or instead the shim code > could be simplified as you did here and avoid distinguish between the two?
There's an argument for improving the correctness of this, yeah. As you say I don't think it actually makes any meaningful difference, but it'll help anyone who's comparing it to the spec. > Have you looked at how to get the TPM2.0 event logs from Linux? The TCG EFI > Protocol > Specification mentions that all events generated after a > EFI_TCG2_GET_EVENT_LOG call > shall be stored in a EFI_CONFIGURATION_TABLE that could be retrieved by the > OS before > a call to ExitBootServices(). > > I see that shim calls GetEventLogs() to trigger this switch and your patch > doesn't. > But Linux still doesn't have support to lookup this table anyways, so I think > it's OK. I think this is a bug in shim. The right place to do this is in the EFI boot stub in the kernel - otherwise the kernel has to source this event information from multiple locations. But now that it's out there, we'll probably have to handle the configurationt able as well. > It's also mentioned in the TCG ACPI (1.2 rev 8, February 2017) and TCG PC > Client PFP > (rev 00.49, January 2017) specifications, that the TPM2 ACPI table has > optional fields > for the Log Area Start Address (LASA) and Log Area Minimum Length (LAML). So > that would > be similar to the TPM1.2 TCPA ACPI table. I guess Linux should need support > for both? I really hope that there are no implementations where there's a difference between the information in ACPI and any other source, but I guess we'll find out. That's going to end up being a problem for the kernel rather than grub, anyway. -- Matthew Garrett | mj...@srcf.ucam.org _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel