Re: TPM support within Grub2

[Daniel Kiper]

On Mon, Jul 16, 2018 at 12:33:42PM -0400, Daniel P. Smith wrote:
> On 07/16/2018 08:06 AM, 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.
>
> I can align Matthew's code or if he would like, he is more than welcome
> to collaborate on the solution.

Both options work for me.

> > 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.
>
> Yes, I figured I would be using the verifier framework. The only

Great!

> suggestion I would have based on my work is that I am going to have to
> establish a TPM event log since I will be doing raw IO with the TPM. I
> think it would be useful if the verifier framework had an event log
> component that verifier modules could log events that they want to have
> passed to the OS kernel being booted. For an example of how to pass the

If you need that may I ask you to add this functionality on top of
existing verifiers framework? I think that you can start your work
with the branch which I posted earlier. In a week or two I will post
its updated version on the list for review.

> log along to the OS kernel, for TrenchBoot the plan is to pass via the
> setup data boot protocol field of Linux. For mutliboot kernels, the log

OK.

> could easily be passed as a mb module. Let me know what you think.

If you consider a module then I would like to ask you to add a header at
the beginning of the log which clearly identifies its type. This way the
OS boot will not depend on the module order or something like that. If
that does not work for you then you can add a tag similar to module but
with an extra member identifying the type of provided data.

By the way, I think that we should focus on Multiboot2 protocol only.

> > And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 
> > somehow?
>
> Phil's work is dealing with the TSS/TIS software layers which provide
> higher abstractions over the TPM. For TPM2 in the absence of or distrust
> in the EFI firmware, it is possible to do a raw IO interface directly
> with the TPM. An example of doing that can be seen in tboot, which if
> you look is a bit more complex than the TPM 1.2 interface.

OK but IIRC there were also low level drivers in it. If it is true then
we could steal them.

WRT EFI and TPM. I think that by default TPM (2.0) GRUB2 drivers should
use EFI infrastructure to control the TPM. Though there should be an option
to skip the EFI stuff and drive the TPM directly.

Daniel