[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Graf
Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
Date: Mon, 14 Jan 2019 11:25:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 01/11/2019 11:58 AM, Leif Lindholm wrote:
On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
Am 10.01.2019 um 09:12 schrieb Michael Chang <address@hidden>:


With the advent of new verifier framework and shim lock protocol support
to the grub's community, we are driving to the world of UEFI Secure
Boot, well, almost ..

There is a missing piece in the puzzle remaining, that is booting linux
kernel via it's own EFI Handover Protocol's entry. Strictly speaking,
the interface is not part of the UEFI Secure Boot, but we have to use it
to avoid problem of using UEFI LoadImage Protocol, which will not work
with shim and it's Machine Owner Key (MOK) as they are not part of
firmware's KEK and db.
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 we would only need to lobby with platform vendors to include
our public key in the delivered Keystore in parallel and everything
would "just work".

The only reason shim needs to provide its own key management is that
on most x86 systems, we (and customers) don't have control over the
keystore, right? We can just push to not have that problem on ARM.
Sure. That's a valid (and I think Ard would say preferable) decision,
and should "just work" with upstream GRUB. But that's for each distro
to decide.

Am I missing anything?
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.

It all comes down to who wants to make sure the key is already in
shipped systems..

On ARM, I don't see us in a world (yet) where you buy systems off-the-shelf and a MS key is installed and no other key can be installed. In fact, for attestation, I would claim that disabling secure boot carries about as much attesting into the system as using a MS signed boot loader.

So if say SBBR just mandates that secure boot is disabled by default and that custom keys have to be installable in the system, I think we're mostly good, no?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]