Re: TPM support within Grub2

[Daniel P. Smith]

On 07/17/2018 01:22 PM, Philip Tricca wrote:
> 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.
>>
>>> 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
>> 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
>> 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
>> could easily be passed as a mb module. Let me know what you think.
>>
>>> 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.
> 
> This is false. The APIs from the TSS are ignorant of and unrelated to
> the TIS. Further, the "System API" has a 1:1 correspondence with
> TPM2 commands effectively providing no abstraction beyond the
> serialization of C types to / from the TPM2 command / response byte
> stream. This is why we recommend that only firmware and "expert"
> applications use it directly.

It was a misnomer to throw TIS in that statement since TSS is really the
software part, bad habit on my part to refer to them collectively. I was
just making a short collective statement that TSS as a whole provides a
set of layers to provide higher abstractions and yes one of those layers
is the one is the C code that implements the hardware interface. My
apologies for the vague statement.

> Philip
> 

v/r,
dps