grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/3] Core TPM support


From: Javier Martinez Canillas
Subject: Re: [PATCH 3/3] Core TPM support
Date: Tue, 20 Jun 2017 00:01:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 06/19/2017 05:38 AM, Matthew Garrett wrote:
> 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.
>

Ok.
 
>> 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.
>

Agreed. Let's see how this could be handled once the kernel has support to get 
the logs
from the EFI_TCG2_FINAL_EVENTS_TABLE and the TPM2 ACPI table.

>> 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.
> 

Yes. I would guess that there are firmwares out there that are following the 
old specs,
so not filling these new TPM2 LASA && LAML fields and instead storing the logs 
in the
EFI_TCG2_FINAL_EVENTS_TABLE. But we can later find out what the firmwares are 
actually
doing and as you said this is a problem for Linux and not grub2 anyways. I just 
asked in
case you had already looked how to get the TPM2.0 event logs from the OS.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat



reply via email to

[Prev in Thread] Current Thread [Next in Thread]