From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ffWLZ-0007Z9-GV for mharc-grub-devel@gnu.org; Tue, 17 Jul 2018 16:13:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ffTXW-0006Tm-Ap for grub-devel@gnu.org; Tue, 17 Jul 2018 13:13:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ffTXS-0005nP-9m for grub-devel@gnu.org; Tue, 17 Jul 2018 13:13:30 -0400 Received: from mga01.intel.com ([192.55.52.88]:36994) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ffTXR-0005mf-VI for grub-devel@gnu.org; Tue, 17 Jul 2018 13:13:26 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 10:13:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,366,1526367600"; d="scan'208";a="73119295" Received: from jake.sc.intel.com (HELO intel.com) ([10.3.66.72]) by fmsmga001.fm.intel.com with ESMTP; 17 Jul 2018 10:13:24 -0700 Date: Tue, 17 Jul 2018 10:22:01 -0700 From: Philip Tricca To: "Daniel P. Smith" Cc: Daniel Kiper , daniel.kiper@oracle.com, eric.snowberg@oracle.com, javierm@redhat.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: <20180717172201.GB19516@intel.com> References: <20180702163508.GC1111@router-fw-old.local.net-space.pl> <20180716120612.GA12081@router-fw-old.local.net-space.pl> <671c05e8-b260-82a0-b54f-6da84f3d403b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <671c05e8-b260-82a0-b54f-6da84f3d403b@gmail.com> 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.88 X-Mailman-Approved-At: Tue, 17 Jul 2018 16:13:19 -0400 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: Tue, 17 Jul 2018 17:13:31 -0000 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. Philip