Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM

[Alexander Graf]

On 22.01.19 07:35, Michael Chang wrote:
> 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 <address@hidden> 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.

Yes, I think we will end up with 3 cases:

  1) MS signed boot flow
  2) SUSE (distro) signed boot flow
  3) End user signed boot flow

For 1) we need shim. For 2 and 3 we should use the native KEK
mechanisms. It's up to the end user to decide which one he wants to use.

So as distro it's our task to enable users to do what they want. Hence
we should support all 3 cases well. And obviously because of that, grub
should too :).


Alex