[Top][All Lists]

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

Re: TPM support within Grub2

From: Daniel P. Smith
Subject: Re: TPM support within Grub2
Date: Wed, 18 Jul 2018 16:39:09 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 07/18/2018 12:27 PM, Javier Martinez Canillas wrote:
> On 07/17/2018 06:57 PM, Philip Tricca wrote:
>> On Mon, Jul 16, 2018 at 02:06:12PM +0200, Daniel Kiper wrote:
>>> On Mon, Jul 02, 2018 at 06:35:08PM +0200, Daniel Kiper wrote:
>>>> Hi Daniel,
>>>> On Sun, Jul 01, 2018 at 07:09:30PM -0400, Daniel P. Smith wrote:
>>>>> Greetings,
>>>>> I have a measured boot implementation I have been working on that
>>>>> introduces a DRTM relocator that I would like to eventually upstream.
>>>>> This work does rely on the ability to access a TPM 1.2 chip from within
>>>>> Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
>>>>> support[1] but that is limited to UEFI environments. My target
>>>>> environment uses Coreboot with the TCG BIOS payload to launch the
>>>>> environment. For TPM support I am using code picked out of the
>>>>> TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
>>>>> would like to see if I could find a way to generically introduce TPM
>>>>> support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
>>>>> TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
>>>>> implementations TPM support is include as an x86 device when in fact
>>>>> they can also be found in ARM devices, which is on my wish list of
>>>>> future devices I would like to support. With all of this in mind, I
>>>>> wanted to open a discussion on the best way to implement generic TPM
>>>>> support. In Matthew's approach TPM is implemented under
>>>>> grub-core/commands while TrustedGRUB2 is split between grub-core/kern
>>>>> and grub-core/tpm. IMHO TPM functionality should be divided into HW
>>>>> interfaces, TPM command processing, and higher order TPM operations. If
>>>>> the logic was segmented in this manner, what are other's opinions on
>>>>> where segments of logic should reside within the Grub2 source tree?
>>>>> [1]
>>>>> [2]
>>> In general I am not against reorganization you are mentioning above.
>>> Though I think that then you should rearange Matthew code and repost
>>> it. Of course if Matthew does not object.
>>> Another thing is the verifiers framework. It would be nice if you could
>>> hook your work there. Though you have to remember about other users like
>>> UEFI secure boot 
>>> (;
>>> I am going to revive work on this patch) or GPG signatures. So, please
>>> take a look at that code at git://,
>>> phcoder/verifiers branch. If it works for you I will post the patches,
>>> with minor fixes and improvements which are worth doing, for review (of
>>> course if Vladimir does not object). If you discover any issues with the
>>> verifiers framework just drop me a line and then we will try to fix them.
>>> And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 
>>> somehow?
>> It's possible to use at least one of the APIs we've been developing in
>> Grub2 but I'm not sure the patches under review require this. It's been
>> a year now since I've reviewed these patches but AFAIK they don't
>> require any TPM2 functions beyond what the UEFI TrEE protocol exposes.
> That's correct.
>> I have had a few people ask about combining Grub2s support for LUKS
>> volumes with the key usage policy from the TPM2 as a way to ensure the
>> integrity of the firmware before releasing a key used to decrypt the
>> LUKS volume. In this case using some of the APIs / libraries we've been
>> developing ( would make sense
>> since the TrEE protocol doesn't expose any of the interfaces we would
>> require: key creation & loading, policy sessions etc.
>> There would be a small amout of development work to implement an adapter
>> to sit between the tss2-sys library and the TrEE 'SubmitCommand'
>> function though. We have a standard API for this and have used it as the
>> basis for our support on Linux and Windows so I don't expect a UEFI
>> implementation to be much work if it becomes necessary. I do not however
>> believe this is required for the work under review.
> I wonder if we want something like the System API in GRUB2 or just a set of
> TPM2 commands implemented using the EFI_TCG2_SUBMIT_COMMAND as you said. Is
> what Microsoft is doing in its lsvmload [0] to implement its Shielded VM [1].

For me the issue is that I am working in coreboot environments where
UEFI is not present. Second, until OEM's stop including the kitchen sink
in their UEFI builds, I hold UEFI suspect and would like to reduce the
chance that it can interfere with my interactions with the TPM. So when
I get to TPM2, I will likely be looking to just do the I/O operations
and marshaling directly. This is getting to what I was suggesting in the
initial email that layer the abstractions so efi kernel can use TrEE by
default and for either override or for non-efi have the i386 kernel
handle raw I/O. Then a tpm lib or command module can expose TPM
operations that things like LUKS or TrenchBoot can leverage.

> The lsvmload is an EFI binary that's executed before the boot-loader and it
> is used just to unseal a key to unlock an encrypted partition where the real
> boot-loader is stored.
> [0]:
> [1]: 
> Something like this can also be built on top of Matthew's current patch-set.
>> Regards,
>> Philip
> Best regards,

reply via email to

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