From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1glpYO-0006Ir-A3 for mharc-grub-devel@gnu.org; Tue, 22 Jan 2019 01:28:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glpYL-0006Hm-8G for grub-devel@gnu.org; Tue, 22 Jan 2019 01:28:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glpUc-0004El-Ri for grub-devel@gnu.org; Tue, 22 Jan 2019 01:25:04 -0500 Received: from smtp2.provo.novell.com ([137.65.250.81]:56283) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glpUc-0004CZ-7O for grub-devel@gnu.org; Tue, 22 Jan 2019 01:25:02 -0500 Received: from mazu (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by smtp2.provo.novell.com with ESMTP (TLS encrypted); Mon, 21 Jan 2019 23:24:53 -0700 Date: Tue, 22 Jan 2019 14:24:49 +0800 From: Michael Chang To: The development of GNU GRUB Cc: Leif Lindholm , Alexander Graf , Ard Biesheuvel , Matthew Garrett , Benjamin Brunner Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM Message-ID: <20190122062449.GC25522@mazu> Mail-Followup-To: The development of GNU GRUB , Leif Lindholm , Alexander Graf , Ard Biesheuvel , Matthew Garrett , Benjamin Brunner References: <20190110081208.GA5021@mazu> <1CE00885-C88C-4D0C-B41C-3BBDDB65F716@suse.de> <20190111105854.4byy3hjcft6oeziy@bivouac.eciton.net> <20190114045829.GC5833@mazu> <20190114091421.GE5833@mazu> <20190114184228.7jhtuzhctquwbumx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190114184228.7jhtuzhctquwbumx@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 137.65.250.81 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, 22 Jan 2019 06:28:54 -0000 On Mon, Jan 14, 2019 at 01:42:29PM -0500, Peter Jones wrote: > On Mon, Jan 14, 2019 at 05:14:21PM +0800, Michael Chang wrote: > > > > 3. The Shim's fallback mode has been used to recreate boot entries after > > > > firmware update for x86, not sure if that any problem for ARM. > > > > > > It thought fallback was a separate binary? If the distros sign that, > > > there is no reason we couldn't load it straight from a Boot#### or > > > PlatformRecovery#### entry. > > > > Wouldn't those entry be lost after firmware update like all others? > > A firmware update *shouldn't* clobber that, but that model isn't right > in any case. We still have to use the default boot path for that, > because it handles the case where you replace a failed mainboard, the > case where a vendor ships a firmware that clobbers boot variables for > years on end (though currently that case is broken until I implement > boot loop detection.) > > > And also without any boot entry firmware will pick default boot path, > > that is grub may be loaded so we need to implant some logic to run > > fallback.efi to recreate boot entry including 'new' default then reboot > > to it. > > You also don't always want to just boot directly after going through the > fallback case, either. Even if you implemented this in grub you'd want > a reboot after fixing the boot variables, because the value in PCR[1] on > tpm2 will be incorrect until after a reboot. > > > > > > As I understand it, there was a concern with the wording in UEFI > > > > > 2.(3?, 4?) that made it possible to interpret it such that only > > > > > one key had to be supported. > > If I'm thinking of what you're thinking of, the issue was one > *signature* in the binary, rather than one *key* in db. The short > version of the story is the PE spec doesn't explicitly say the > signatures are an array, and MS hadn't interpreted it that way until I > interpreted it as one, so their version of "multiple signatures" was > done through creative x509 countersigning structures. These days > signtool.exe implements the same thing pesign does, and treats the > signature entry in the binary as an array of aligned WIN_CERTIFICATE > structs, with one signature each. > > None of that is really relevant here, though. > > > > > > It all comes down to who wants to make sure the key is already > > > > > in shipped systems.. > > > > > > > > Do you think all vendors and distro will have to use common secure > > > > channel to communicate the key distribution related issues ? > > > > > > Define 'secure'. I don't think the distros should be sharing any > > > secrets with the vendor, but I guess they would have to establish some > > > kind of trust if the any keys get installed in the factory. > > > This is similar to how you get your public key hash fused into your > > > silicon when you order secure parts from a silicon vendor. > > > > True. It reminds me UEFI used to propose the Audit mode for the factory > > usage, > > "Factory usage" isn't the use case that was discussed for Audit Mode. > The point of it is to ship server-class hardware in a state where during > initial deployment you can switch to using your site-specific keys and > hashes of individual binaries (i.e. option ROMs) you need in order to do > your own signing, without having to have a prior enrolled KEK entry. > > We should really implement support for it everywhere. Thanks for the clarification. Neverthelast it sounds to me the same thing can be *misused* for mass key provisioning in the factroy. > > > and if I remember correctly TPM is required to ensure everything > > is not tampered in factory. But TBH I have lost track of it since it has > > no real demand for linux distro. > > TPM is not required for audit mode at all. What *is* needed is to > expose to userland the data in the IEIT config table - the log of what > got verified for Secure Boot with which keys and hashes. I wrote some > code for this last year, but got mired down in how EFI config table > handling in general works. I'll ask Javier Martinez to have a look at > reviving that, along with the work he's already to expose the tpm2 log > properly, since they are generally useful together. Glad to hear that you'll revive it and continue to move on. :) Thanks, Michael > > -- > Peter > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel