Re: TPM support within Grub2

[Philip Tricca <philip.b.tricca@intel.com>]

On Wed, Jul 18, 2018 at 06:27:15PM +0200, 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] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
> >>>> [2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
> >>
> >> 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 (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
> >> I am going to revive work on this patch) or GPG signatures. So, please
> >> take a look at that code at git://git.savannah.gnu.org/grub.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 (https://github.com/tpm2-software/tpm2-tss) 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.

I've been threatening to implement this for a while now. The majority of
the work involved will be in the build and the implementation of a new
TCTI module that sits on top of the TrEE protocol driver. The system API
code (tss2-sys) would remain unchanged.

> Is
> what Microsoft is doing in its lsvmload [0] to implement its Shielded VM [1].

Hadn't seen this. Thanks.

Philip

> 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]: https://github.com/Microsoft/lsvmtools/blob/master/lsvmutils/tpm2.c
> [1]: https://events.static.linuxfound.org/sites/events/files/slides/LinuxCon%20Mike%20Brasher.pdf
> 
> Something like this can also be built on top of Matthew's current patch-set.
> 
> > Regards,
> > Philip
> > 
> 
> Best regards,
> -- 
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement
> Red Hat