Re: TPM support within Grub2

[Philip Tricca]

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.

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.

Regards,
Philip