From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1glpfE-0007vA-B9 for mharc-grub-devel@gnu.org; Tue, 22 Jan 2019 01:36:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glpfA-0007u0-Uq for grub-devel@gnu.org; Tue, 22 Jan 2019 01:35:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glpfA-0003LL-0U for grub-devel@gnu.org; Tue, 22 Jan 2019 01:35:56 -0500 Received: from smtp2.provo.novell.com ([137.65.250.81]:45757) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glpf8-0003JQ-K9 for grub-devel@gnu.org; Tue, 22 Jan 2019 01:35:54 -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:35:48 -0700 Date: Tue, 22 Jan 2019 14:35:43 +0800 From: Michael Chang To: Alexander Graf Cc: Matthew Garrett , The development of GNU GRUB , Ard Biesheuvel , Leif Lindholm , Peter Jones , Benjamin Brunner Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM Message-ID: <20190122063543.GD25522@mazu> Mail-Followup-To: Alexander Graf , Matthew Garrett , The development of GNU GRUB , Ard Biesheuvel , Leif Lindholm , Peter Jones , Benjamin Brunner References: <20190110081208.GA5021@mazu> <1CE00885-C88C-4D0C-B41C-3BBDDB65F716@suse.de> <8e5f54d8-0298-7a76-092d-ec79e1c0508e@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e5f54d8-0298-7a76-092d-ec79e1c0508e@suse.de> 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:35:59 -0000 On Fri, Jan 11, 2019 at 08:49:28PM +0100, Alexander Graf wrote: > > > On 11.01.19 20:32, Matthew Garrett wrote: > > On Thu, Jan 10, 2019 at 12:59 AM Alexander Graf wrote: > >> So really dumb question here: What if we didn't use the MS key? What if instead, we just provide a SUSE/openSUSE key and give customers the ability to sign their own grub+Linux binaries? > > > > Then you end up blocking install of any Linux distribution that isn't > > big enough to have every ARM server vendor include their keys. This is > > the exact reason we chose not to explore this approach on x86 - we > > didn't want Red Hat to have privileges that, say, Gentoo didn't. The > > problem is somewhat mitigated if systems are guaranteed to be shipped > > with Secure Boot disabled, but you then still end up encouraging > > vendor lock-in - it becomes difficult to migrate systems from one > > distribution to another without manual re-keying. > > But on the other hand (given we gave people the right tools), wouldn't > that also enable end users to secure things down to *their* stack? > > I you are big-customer and you only want your own big-customer branded > Linux to run on your servers, not a stock SUSE or Red Hat or whatever > OS, then you would have the ability to easily add your key to the key store. > > Isn't that a much more preferable approach? I personally would advise > OEMs to simply not enable secure boot by default and then have everyone > give instructions how to either > > a) install the distro key and/or > b) provide easy means to resign binaries themselves and install those keys > > At the end of the day, as a customer I care much more about integrity of > *my* stack, rather than whether the boot chain is MS approved, no? I think both of you are all correct standing from different point of view. It is then how to provide different solution to satisfy the two ends to make it a more completed one. My two cents. Thanks, Michael > > > Alex