From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1fgACg-0004TK-Vs for mharc-grub-devel@gnu.org; Thu, 19 Jul 2018 10:46:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fgACe-0004T9-6y for grub-devel@gnu.org; Thu, 19 Jul 2018 10:46:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fgACb-0001BK-15 for grub-devel@gnu.org; Thu, 19 Jul 2018 10:46:48 -0400 Received: from mga05.intel.com ([192.55.52.43]:51362) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fgACa-00017W-Ix for grub-devel@gnu.org; Thu, 19 Jul 2018 10:46:44 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 07:46:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,374,1526367600"; d="scan'208";a="247073924" Received: from jake.sc.intel.com (HELO intel.com) ([10.3.66.72]) by fmsmga006.fm.intel.com with ESMTP; 19 Jul 2018 07:46:38 -0700 Date: Thu, 19 Jul 2018 07:55:19 -0700 From: Philip Tricca To: Javier Martinez Canillas Cc: Daniel Kiper , dpsmith.dev@gmail.com, daniel.kiper@oracle.com, eric.snowberg@oracle.com, jonmccune@google.com, kanth.ghatraju@oracle.com, keng-yu.lin@hpe.com, konrad.wilk@oracle.com, leif.lindholm@linaro.org, mjg59@srcf.ucam.org, phcoder@gmail.com, ross.philipson@oracle.com, grub-devel@gnu.org Subject: Re: TPM support within Grub2 Message-ID: <20180719145519.GD19516@intel.com> References: <20180702163508.GC1111@router-fw-old.local.net-space.pl> <20180716120612.GA12081@router-fw-old.local.net-space.pl> <20180717165756.GA19516@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.43 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:46:50 -0000 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