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