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] 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. 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]: 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, > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
