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

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

[Michael Chang]

Hi,

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.

In other words, with the current state of implementation, ARM is still
not able to support Secure Boot and will end up with security violation
as long as LoadImage is performed to boot the kernel as firmware's blob.
The shim-lock support turns out to be useless, unless we could change it
to use some sort of kernel's own interface, like UEFI handover, is a
good candidate for me (sorry I'm aware of any other choice for ARM).

The x86 might be working with shim, since 32-bit entry is used. But IIUC
linux kernel recommends efi handover entry than 32-bit for efi booting
since it is less tied to bootloader and thus makes booting problem more
easy and obvious to fix by the kernel itself. For that reason the
support will be needed in the long run regardless secure boot since it
provides better prospect than 32-bit entry.

I think it is about time to discuss and figure out a common way to bring
UEFI handover support to the x86 and ARM architectures both having UEFI
running. Many downstream distributions have already been carrying
diverged linuxefi patch for a long time and I think our ARM friends may
not want to repeat the same story. :)

Any idea and suggestion for the topic is welcome.

Thanks,
Michael

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

[Alexander Graf]

> Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> 
> Hi,
> 
> 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.

Am I missing anything?


Alex

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

[Leif Lindholm]

On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > 
> > Hi,
> > 
> > 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..

/
    Leif

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

[Ard Biesheuvel]

On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>
> On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > >
> > > Hi,
> > >
> > > 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.

I don't understand what this means.

> 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.
> >

The 'problem' of using the UEFI LoadImage protocol is the whole point
of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
entirely, but in a controlled way.

> > 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..
>

I will repeat the same thing I have been saying since 2013: carrying
over Shim to other architectures is a mistake. We could have a simple
and clean secure boot architecture on arm64, where the firmware
authenticates GRUB, and GRUB calls LoadImage() which authenticates the
kernel against the firmware keys. All we need for that is to ensure
that the distros get their act together, and work with the industry to
get Redhat, Canonical and Suse keys into the KEK and/or db databases
by default.

Instead, we are having this discussion again, how we can circumvent
authentication checks so that GRUB can load what are essentially
unverified binaries (from the POV of the firmware), authenticated
against certificates that are kept in unauthenticated UEFI variables.
Canonical is even shipping a GRUB with cosmic and disco now that is
signed with their master key, and happily boots anything if shim is
not loaded, which makes it impossible to ever move to a model where
the canonical key is in the UEFI db rather than in the MOK database.

So I strongly suggest that you make things work without shim, relying
on a monolithic distro signed GRUB which authenticates against the
UEFI database only. Should the need ever arise, we can always
introduce shim at a later date.

In fact, if I were running a shrink wrapped distro and did not have to
rely on MS signed option ROMs, I wouldn't even want the MS key in my
UEFI db if all I want to run is SUSE.

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

[Michael Chang]

On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote:
> On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> >
> > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > > >
> > > > Hi,
> > > >
> > > > 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.
> 
> I don't understand what this means.

From me it means 'maybe' we have to consider common linuxefi loader for
ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock
protocol. It doesn't mean switching over from linux to linuxefi
completely, just offering it as another boot command (like linux16 for
legacy pc bios), and let the distribution choose what to do.

> 
> > 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.
> > >
> 
> The 'problem' of using the UEFI LoadImage protocol is the whole point
> of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
> entirely, but in a controlled way.

By far we don't know what UEFI Secure Boot support in ARM will be like.
There is rumor that Microsoft will also host signing service for ARM
secure boot, so the situation is simialr to the beginning of x86, and is
reasonle to relate it to shim since it was requested to satisfy that.

> 
> > > 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..
> >
> 
> I will repeat the same thing I have been saying since 2013: carrying
> over Shim to other architectures is a mistake. We could have a simple
> and clean secure boot architecture on arm64, where the firmware
> authenticates GRUB, and GRUB calls LoadImage() which authenticates the
> kernel against the firmware keys. All we need for that is to ensure
> that the distros get their act together, and work with the industry to
> get Redhat, Canonical and Suse keys into the KEK and/or db databases
> by default.

I agree that technically it results better and clean boot stack. The
challege is on that do we consider to host central authority responsible
for the key signing and code review in lieu of vendor? Or do we agree to
trust whatever key giving out to the vendor? For x86, I think currently
microsoft takes the responsiblity to code review and authenicate the
identity of key owner and that costs a lot effort.

> 
> Instead, we are having this discussion again, how we can circumvent
> authentication checks so that GRUB can load what are essentially
> unverified binaries (from the POV of the firmware), authenticated
> against certificates that are kept in unauthenticated UEFI variables.
> Canonical is even shipping a GRUB with cosmic and disco now that is
> signed with their master key, and happily boots anything if shim is
> not loaded, which makes it impossible to ever move to a model where
> the canonical key is in the UEFI db rather than in the MOK database.

The point of having MOK is that once anything goes wrong with grub, we
can just revoke MOK and we don't need to walk through the nightmare of
revoking firmware's key. 

IMHO we also need to think about misc shim features can be moved to
grub2 if necessary.

> 
> So I strongly suggest that you make things work without shim, relying
> on a monolithic distro signed GRUB which authenticates against the
> UEFI database only. Should the need ever arise, we can always
> introduce shim at a later date.

OK, that seems to answer my question above. And again I think what's
missing for current grub is efi handover protocol support, which doesn't
conflict with existing LoadImage boot entry. (we run in circle again).

> 
> In fact, if I were running a shrink wrapped distro and did not have to
> rely on MS signed option ROMs, I wouldn't even want the MS key in my
> UEFI db if all I want to run is SUSE.

Yes, same here. :) That's why in openSUSE we provided option to disable
shim installation and use pristine grub2-install, of course in this case
users are on their own when things are not working.

Thanks,
Michael

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

[Ard Biesheuvel]

On Mon, 14 Jan 2019 at 08:30, Michael Chang <mchang@suse.com> wrote:
>
> On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote:
> > On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > >
> > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > 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.
> >
> > I don't understand what this means.
>
> From me it means 'maybe' we have to consider common linuxefi loader for
> ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock
> protocol. It doesn't mean switching over from linux to linuxefi
> completely, just offering it as another boot command (like linux16 for
> legacy pc bios), and let the distribution choose what to do.
>

The ARM and arm64 kernels expect to be invoked as an UEFI loader,
i.e., via the PE/COFF entry point with the system table pointer in x1.
Adding any infrastructure at all to the kernel to permit it to be
booted from UEFI/GRUB in a slightly different way is not maintainable,
and the stub<->kernel boot protocol is an implementation detail and I
am not comfortable promoting that to something bootloaders implement
directly.

> >
> > > 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.
> > > >
> >
> > The 'problem' of using the UEFI LoadImage protocol is the whole point
> > of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
> > entirely, but in a controlled way.
>
> By far we don't know what UEFI Secure Boot support in ARM will be like.
> There is rumor that Microsoft will also host signing service for ARM
> secure boot, so the situation is simialr to the beginning of x86, and is
> reasonle to relate it to shim since it was requested to satisfy that.
>

Microsoft does host signing services for ARM, yes. But that does not
mean we have to lock ourselves into using it as the only signing
service.

> >
> > > > 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..
> > >
> >
> > I will repeat the same thing I have been saying since 2013: carrying
> > over Shim to other architectures is a mistake. We could have a simple
> > and clean secure boot architecture on arm64, where the firmware
> > authenticates GRUB, and GRUB calls LoadImage() which authenticates the
> > kernel against the firmware keys. All we need for that is to ensure
> > that the distros get their act together, and work with the industry to
> > get Redhat, Canonical and Suse keys into the KEK and/or db databases
> > by default.
>
> I agree that technically it results better and clean boot stack. The
> challege is on that do we consider to host central authority responsible
> for the key signing and code review in lieu of vendor? Or do we agree to
> trust whatever key giving out to the vendor? For x86, I think currently
> microsoft takes the responsiblity to code review and authenicate the
> identity of key owner and that costs a lot effort.
>

But whick key owner? What if whatever Microsoft signs is entirely
uninteresting to me? For the server use case, it is highly likely that
I only care about the distro key, and nothing else. Having to carry
Microsoft's key because all the distros conspired to make that the
only basket I can put my eggs in sounds like a bad idea from security
pov.

Shim is a fix for a problem that does not currently exist on ARM.
Let's not create it ourselves.

> >
> > Instead, we are having this discussion again, how we can circumvent
> > authentication checks so that GRUB can load what are essentially
> > unverified binaries (from the POV of the firmware), authenticated
> > against certificates that are kept in unauthenticated UEFI variables.
> > Canonical is even shipping a GRUB with cosmic and disco now that is
> > signed with their master key, and happily boots anything if shim is
> > not loaded, which makes it impossible to ever move to a model where
> > the canonical key is in the UEFI db rather than in the MOK database.
>
> The point of having MOK is that once anything goes wrong with grub, we
> can just revoke MOK and we don't need to walk through the nightmare of
> revoking firmware's key.
>

Or revoke GRUB?

> IMHO we also need to think about misc shim features can be moved to
> grub2 if necessary.
>

Yes.

> >
> > So I strongly suggest that you make things work without shim, relying
> > on a monolithic distro signed GRUB which authenticates against the
> > UEFI database only. Should the need ever arise, we can always
> > introduce shim at a later date.
>
> OK, that seems to answer my question above. And again I think what's
> missing for current grub is efi handover protocol support, which doesn't
> conflict with existing LoadImage boot entry. (we run in circle again).
>
> >
> > In fact, if I were running a shrink wrapped distro and did not have to
> > rely on MS signed option ROMs, I wouldn't even want the MS key in my
> > UEFI db if all I want to run is SUSE.
>
> Yes, same here. :) That's why in openSUSE we provided option to disable
> shim installation and use pristine grub2-install, of course in this case
> users are on their own when things are not working.
>

So non-shim boot is going to be a second class citizen?

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

[Michael Chang]

On Mon, Jan 14, 2019 at 08:41:21AM +0100, Ard Biesheuvel wrote:
> On Mon, 14 Jan 2019 at 08:30, Michael Chang <mchang@suse.com> wrote:
> >
> > On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote:
> > > On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > > >
> > > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > 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.
> > >
> > > I don't understand what this means.
> >
> > From me it means 'maybe' we have to consider common linuxefi loader for
> > ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock
> > protocol. It doesn't mean switching over from linux to linuxefi
> > completely, just offering it as another boot command (like linux16 for
> > legacy pc bios), and let the distribution choose what to do.
> >
> 
> The ARM and arm64 kernels expect to be invoked as an UEFI loader,
> i.e., via the PE/COFF entry point with the system table pointer in x1.
> Adding any infrastructure at all to the kernel to permit it to be
> booted from UEFI/GRUB in a slightly different way is not maintainable,
> and the stub<->kernel boot protocol is an implementation detail and I
> am not comfortable promoting that to something bootloaders implement
> directly.
> 
> > >
> > > > 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.
> > > > >
> > >
> > > The 'problem' of using the UEFI LoadImage protocol is the whole point
> > > of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
> > > entirely, but in a controlled way.
> >
> > By far we don't know what UEFI Secure Boot support in ARM will be like.
> > There is rumor that Microsoft will also host signing service for ARM
> > secure boot, so the situation is simialr to the beginning of x86, and is
> > reasonle to relate it to shim since it was requested to satisfy that.
> >
> 
> Microsoft does host signing services for ARM, yes. But that does not
> mean we have to lock ourselves into using it as the only signing
> service.

Hm. But that doesn't help if Microsoft requests shim. In the end we have
to maintain two different methods for ARM. My question here is couldn't
we just pick one of them and never look back ?

> 
> > >
> > > > > 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..
> > > >
> > >
> > > I will repeat the same thing I have been saying since 2013: carrying
> > > over Shim to other architectures is a mistake. We could have a simple
> > > and clean secure boot architecture on arm64, where the firmware
> > > authenticates GRUB, and GRUB calls LoadImage() which authenticates the
> > > kernel against the firmware keys. All we need for that is to ensure
> > > that the distros get their act together, and work with the industry to
> > > get Redhat, Canonical and Suse keys into the KEK and/or db databases
> > > by default.
> >
> > I agree that technically it results better and clean boot stack. The
> > challege is on that do we consider to host central authority responsible
> > for the key signing and code review in lieu of vendor? Or do we agree to
> > trust whatever key giving out to the vendor? For x86, I think currently
> > microsoft takes the responsiblity to code review and authenicate the
> > identity of key owner and that costs a lot effort.
> >
> 
> But whick key owner? What if whatever Microsoft signs is entirely
> uninteresting to me? For the server use case, it is highly likely that
> I only care about the distro key, and nothing else. Having to carry
> Microsoft's key because all the distros conspired to make that the
> only basket I can put my eggs in sounds like a bad idea from security
> pov.
> 
> Shim is a fix for a problem that does not currently exist on ARM.
> Let's not create it ourselves.

I am absoutely agree with you, if possible we should avoid shim for ARM
at all. But the problem remains what Microsoft will do and what should
we do as a respond. Will it be like the situation in x86 or will it be
different ? In any case current grub has been working for the case
without Microsoft signs and we are exploring other requrests for Secure
Boot.

> 
> > >
> > > Instead, we are having this discussion again, how we can circumvent
> > > authentication checks so that GRUB can load what are essentially
> > > unverified binaries (from the POV of the firmware), authenticated
> > > against certificates that are kept in unauthenticated UEFI variables.
> > > Canonical is even shipping a GRUB with cosmic and disco now that is
> > > signed with their master key, and happily boots anything if shim is
> > > not loaded, which makes it impossible to ever move to a model where
> > > the canonical key is in the UEFI db rather than in the MOK database.
> >
> > The point of having MOK is that once anything goes wrong with grub, we
> > can just revoke MOK and we don't need to walk through the nightmare of
> > revoking firmware's key.
> >
> 
> Or revoke GRUB?

Which do you mean: grub's binary or key ? I think binary doesn't help as
it has been distributed, so we need to revoke its signing key to
prohibit it from running afterwards.

Do I misunderstand your problem ?

> 
> > IMHO we also need to think about misc shim features can be moved to
> > grub2 if necessary.
> >
> 
> Yes.
> 
> > >
> > > So I strongly suggest that you make things work without shim, relying
> > > on a monolithic distro signed GRUB which authenticates against the
> > > UEFI database only. Should the need ever arise, we can always
> > > introduce shim at a later date.
> >
> > OK, that seems to answer my question above. And again I think what's
> > missing for current grub is efi handover protocol support, which doesn't
> > conflict with existing LoadImage boot entry. (we run in circle again).
> >
> > >
> > > In fact, if I were running a shrink wrapped distro and did not have to
> > > rely on MS signed option ROMs, I wouldn't even want the MS key in my
> > > UEFI db if all I want to run is SUSE.
> >
> > Yes, same here. :) That's why in openSUSE we provided option to disable
> > shim installation and use pristine grub2-install, of course in this case
> > users are on their own when things are not working.
> >
> 
> So non-shim boot is going to be a second class citizen?

Sorry I did not make it clear. Don't get me wrong. It is limited to some
issue related with x86 32bit boot entry and also the setup process
varies by vendors, and we couldn't trouble shoot much if the problem
related to firmware, like some production firmware do not support
multi-signed image and differnt tends to intepret x509 requirement (As a
community project, it is hard to get attendtion from commercial vendor
for such requests).


> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Ard Biesheuvel]

On Mon, 14 Jan 2019 at 10:53, Michael Chang <mchang@suse.com> wrote:
>
> On Mon, Jan 14, 2019 at 08:41:21AM +0100, Ard Biesheuvel wrote:
> > On Mon, 14 Jan 2019 at 08:30, Michael Chang <mchang@suse.com> wrote:
> > >
> > > On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote:
> > > > On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > > > >
> > > > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > 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.
> > > >
> > > > I don't understand what this means.
> > >
> > > From me it means 'maybe' we have to consider common linuxefi loader for
> > > ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock
> > > protocol. It doesn't mean switching over from linux to linuxefi
> > > completely, just offering it as another boot command (like linux16 for
> > > legacy pc bios), and let the distribution choose what to do.
> > >
> >
> > The ARM and arm64 kernels expect to be invoked as an UEFI loader,
> > i.e., via the PE/COFF entry point with the system table pointer in x1.
> > Adding any infrastructure at all to the kernel to permit it to be
> > booted from UEFI/GRUB in a slightly different way is not maintainable,
> > and the stub<->kernel boot protocol is an implementation detail and I
> > am not comfortable promoting that to something bootloaders implement
> > directly.
> >
> > > >
> > > > > 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.
> > > > > >
> > > >
> > > > The 'problem' of using the UEFI LoadImage protocol is the whole point
> > > > of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
> > > > entirely, but in a controlled way.
> > >
> > > By far we don't know what UEFI Secure Boot support in ARM will be like.
> > > There is rumor that Microsoft will also host signing service for ARM
> > > secure boot, so the situation is simialr to the beginning of x86, and is
> > > reasonle to relate it to shim since it was requested to satisfy that.
> > >
> >
> > Microsoft does host signing services for ARM, yes. But that does not
> > mean we have to lock ourselves into using it as the only signing
> > service.
>
> Hm. But that doesn't help if Microsoft requests shim. In the end we have
> to maintain two different methods for ARM. My question here is couldn't
> we just pick one of them and never look back ?
>

Of course. So let's go without shim.

> >
> > > >
> > > > > > 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..
> > > > >
> > > >
> > > > I will repeat the same thing I have been saying since 2013: carrying
> > > > over Shim to other architectures is a mistake. We could have a simple
> > > > and clean secure boot architecture on arm64, where the firmware
> > > > authenticates GRUB, and GRUB calls LoadImage() which authenticates the
> > > > kernel against the firmware keys. All we need for that is to ensure
> > > > that the distros get their act together, and work with the industry to
> > > > get Redhat, Canonical and Suse keys into the KEK and/or db databases
> > > > by default.
> > >
> > > I agree that technically it results better and clean boot stack. The
> > > challege is on that do we consider to host central authority responsible
> > > for the key signing and code review in lieu of vendor? Or do we agree to
> > > trust whatever key giving out to the vendor? For x86, I think currently
> > > microsoft takes the responsiblity to code review and authenicate the
> > > identity of key owner and that costs a lot effort.
> > >
> >
> > But whick key owner? What if whatever Microsoft signs is entirely
> > uninteresting to me? For the server use case, it is highly likely that
> > I only care about the distro key, and nothing else. Having to carry
> > Microsoft's key because all the distros conspired to make that the
> > only basket I can put my eggs in sounds like a bad idea from security
> > pov.
> >
> > Shim is a fix for a problem that does not currently exist on ARM.
> > Let's not create it ourselves.
>
> I am absoutely agree with you, if possible we should avoid shim for ARM
> at all. But the problem remains what Microsoft will do and what should
> we do as a respond. Will it be like the situation in x86 or will it be
> different ? In any case current grub has been working for the case
> without Microsoft signs and we are exploring other requrests for Secure
> Boot.
>

Why does it matter so much what Microsoft will do? If they sign things
you care about, you put their key in KEK. If not, you don't.


> >
> > > >
> > > > Instead, we are having this discussion again, how we can circumvent
> > > > authentication checks so that GRUB can load what are essentially
> > > > unverified binaries (from the POV of the firmware), authenticated
> > > > against certificates that are kept in unauthenticated UEFI variables.
> > > > Canonical is even shipping a GRUB with cosmic and disco now that is
> > > > signed with their master key, and happily boots anything if shim is
> > > > not loaded, which makes it impossible to ever move to a model where
> > > > the canonical key is in the UEFI db rather than in the MOK database.
> > >
> > > The point of having MOK is that once anything goes wrong with grub, we
> > > can just revoke MOK and we don't need to walk through the nightmare of
> > > revoking firmware's key.
> > >
> >
> > Or revoke GRUB?
>
> Which do you mean: grub's binary or key ? I think binary doesn't help as
> it has been distributed, so we need to revoke its signing key to
> prohibit it from running afterwards.
>
> Do I misunderstand your problem ?
>

I guess I am misunderstanding your problem. If anything is wrong which
can be fixed by revocation, why is it not possible to revoke whatever
is actually broken?


> >
> > > IMHO we also need to think about misc shim features can be moved to
> > > grub2 if necessary.
> > >
> >
> > Yes.
> >
> > > >
> > > > So I strongly suggest that you make things work without shim, relying
> > > > on a monolithic distro signed GRUB which authenticates against the
> > > > UEFI database only. Should the need ever arise, we can always
> > > > introduce shim at a later date.
> > >
> > > OK, that seems to answer my question above. And again I think what's
> > > missing for current grub is efi handover protocol support, which doesn't
> > > conflict with existing LoadImage boot entry. (we run in circle again).
> > >
> > > >
> > > > In fact, if I were running a shrink wrapped distro and did not have to
> > > > rely on MS signed option ROMs, I wouldn't even want the MS key in my
> > > > UEFI db if all I want to run is SUSE.
> > >
> > > Yes, same here. :) That's why in openSUSE we provided option to disable
> > > shim installation and use pristine grub2-install, of course in this case
> > > users are on their own when things are not working.
> > >
> >
> > So non-shim boot is going to be a second class citizen?
>
> Sorry I did not make it clear. Don't get me wrong. It is limited to some
> issue related with x86 32bit boot entry and also the setup process
> varies by vendors, and we couldn't trouble shoot much if the problem
> related to firmware, like some production firmware do not support
> multi-signed image and differnt tends to intepret x509 requirement (As a
> community project, it is hard to get attendtion from commercial vendor
> for such requests).
>

OK.

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

[Michael Chang]

On Mon, Jan 14, 2019 at 10:57:10AM +0100, Ard Biesheuvel wrote:
> On Mon, 14 Jan 2019 at 10:53, Michael Chang <mchang@suse.com> wrote:
> >
> > On Mon, Jan 14, 2019 at 08:41:21AM +0100, Ard Biesheuvel wrote:
> > > On Mon, 14 Jan 2019 at 08:30, Michael Chang <mchang@suse.com> wrote:
> > > >
> > > > On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote:
> > > > > On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> > > > > >
> > > > > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > > > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mchang@suse.com>:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > 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.
> > > > >
> > > > > I don't understand what this means.
> > > >
> > > > From me it means 'maybe' we have to consider common linuxefi loader for
> > > > ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock
> > > > protocol. It doesn't mean switching over from linux to linuxefi
> > > > completely, just offering it as another boot command (like linux16 for
> > > > legacy pc bios), and let the distribution choose what to do.
> > > >
> > >
> > > The ARM and arm64 kernels expect to be invoked as an UEFI loader,
> > > i.e., via the PE/COFF entry point with the system table pointer in x1.
> > > Adding any infrastructure at all to the kernel to permit it to be
> > > booted from UEFI/GRUB in a slightly different way is not maintainable,
> > > and the stub<->kernel boot protocol is an implementation detail and I
> > > am not comfortable promoting that to something bootloaders implement
> > > directly.
> > >
> > > > >
> > > > > > 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.
> > > > > > >
> > > > >
> > > > > The 'problem' of using the UEFI LoadImage protocol is the whole point
> > > > > of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
> > > > > entirely, but in a controlled way.
> > > >
> > > > By far we don't know what UEFI Secure Boot support in ARM will be like.
> > > > There is rumor that Microsoft will also host signing service for ARM
> > > > secure boot, so the situation is simialr to the beginning of x86, and is
> > > > reasonle to relate it to shim since it was requested to satisfy that.
> > > >
> > >
> > > Microsoft does host signing services for ARM, yes. But that does not
> > > mean we have to lock ourselves into using it as the only signing
> > > service.
> >
> > Hm. But that doesn't help if Microsoft requests shim. In the end we have
> > to maintain two different methods for ARM. My question here is couldn't
> > we just pick one of them and never look back ?
> >
> 
> Of course. So let's go without shim.

OK. :)

> 
> > >
> > > > >
> > > > > > > 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..
> > > > > >
> > > > >
> > > > > I will repeat the same thing I have been saying since 2013: carrying
> > > > > over Shim to other architectures is a mistake. We could have a simple
> > > > > and clean secure boot architecture on arm64, where the firmware
> > > > > authenticates GRUB, and GRUB calls LoadImage() which authenticates the
> > > > > kernel against the firmware keys. All we need for that is to ensure
> > > > > that the distros get their act together, and work with the industry to
> > > > > get Redhat, Canonical and Suse keys into the KEK and/or db databases
> > > > > by default.
> > > >
> > > > I agree that technically it results better and clean boot stack. The
> > > > challege is on that do we consider to host central authority responsible
> > > > for the key signing and code review in lieu of vendor? Or do we agree to
> > > > trust whatever key giving out to the vendor? For x86, I think currently
> > > > microsoft takes the responsiblity to code review and authenicate the
> > > > identity of key owner and that costs a lot effort.
> > > >
> > >
> > > But whick key owner? What if whatever Microsoft signs is entirely
> > > uninteresting to me? For the server use case, it is highly likely that
> > > I only care about the distro key, and nothing else. Having to carry
> > > Microsoft's key because all the distros conspired to make that the
> > > only basket I can put my eggs in sounds like a bad idea from security
> > > pov.
> > >
> > > Shim is a fix for a problem that does not currently exist on ARM.
> > > Let's not create it ourselves.
> >
> > I am absoutely agree with you, if possible we should avoid shim for ARM
> > at all. But the problem remains what Microsoft will do and what should
> > we do as a respond. Will it be like the situation in x86 or will it be
> > different ? In any case current grub has been working for the case
> > without Microsoft signs and we are exploring other requrests for Secure
> > Boot.
> >
> 
> Why does it matter so much what Microsoft will do? If they sign things
> you care about, you put their key in KEK. If not, you don't.

Somehow I get the impression that Microsoft would like to have full
control to the Secure Boot, that's why they are actively hosting the
signing service to audit every piece running without security risk. If
any other KEK installed, then it can be used to bypass their audit
process and depending on their willing to accept. Once a signed loader
is found compromised, it can also be used to chainload and compromise
Windows as well.

Of course I could be terribly wrong.

> 
> 
> > >
> > > > >
> > > > > Instead, we are having this discussion again, how we can circumvent
> > > > > authentication checks so that GRUB can load what are essentially
> > > > > unverified binaries (from the POV of the firmware), authenticated
> > > > > against certificates that are kept in unauthenticated UEFI variables.
> > > > > Canonical is even shipping a GRUB with cosmic and disco now that is
> > > > > signed with their master key, and happily boots anything if shim is
> > > > > not loaded, which makes it impossible to ever move to a model where
> > > > > the canonical key is in the UEFI db rather than in the MOK database.
> > > >
> > > > The point of having MOK is that once anything goes wrong with grub, we
> > > > can just revoke MOK and we don't need to walk through the nightmare of
> > > > revoking firmware's key.
> > > >
> > >
> > > Or revoke GRUB?
> >
> > Which do you mean: grub's binary or key ? I think binary doesn't help as
> > it has been distributed, so we need to revoke its signing key to
> > prohibit it from running afterwards.
> >
> > Do I misunderstand your problem ?
> >
> 
> I guess I am misunderstanding your problem. If anything is wrong which
> can be fixed by revocation, why is it not possible to revoke whatever
> is actually broken?

Becuase it is released so before you revoke it, it may have been saved
and used as off-line copy by hacker to attack the system. (Again, I
might be over-thinking the problem so feel free to corret me.) 

Thanks,
Michael


> 
> 
> > >
> > > > IMHO we also need to think about misc shim features can be moved to
> > > > grub2 if necessary.
> > > >
> > >
> > > Yes.
> > >
> > > > >
> > > > > So I strongly suggest that you make things work without shim, relying
> > > > > on a monolithic distro signed GRUB which authenticates against the
> > > > > UEFI database only. Should the need ever arise, we can always
> > > > > introduce shim at a later date.
> > > >
> > > > OK, that seems to answer my question above. And again I think what's
> > > > missing for current grub is efi handover protocol support, which doesn't
> > > > conflict with existing LoadImage boot entry. (we run in circle again).
> > > >
> > > > >
> > > > > In fact, if I were running a shrink wrapped distro and did not have to
> > > > > rely on MS signed option ROMs, I wouldn't even want the MS key in my
> > > > > UEFI db if all I want to run is SUSE.
> > > >
> > > > Yes, same here. :) That's why in openSUSE we provided option to disable
> > > > shim installation and use pristine grub2-install, of course in this case
> > > > users are on their own when things are not working.
> > > >
> > >
> > > So non-shim boot is going to be a second class citizen?
> >
> > Sorry I did not make it clear. Don't get me wrong. It is limited to some
> > issue related with x86 32bit boot entry and also the setup process
> > varies by vendors, and we couldn't trouble shoot much if the problem
> > related to firmware, like some production firmware do not support
> > multi-signed image and differnt tends to intepret x509 requirement (As a
> > community project, it is hard to get attendtion from commercial vendor
> > for such requests).
> >
> 
> OK.
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Michael Chang]

On Fri, Jan 11, 2019 at 10:58:54AM +0000, 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 <mchang@suse.com>:
> > > 
> > > Hi,
> > > 
> > > 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.

It will work as far as it goes. I think part of the reason shim was used
is that early x86 UEFI Secure Boot shipped without function to disable
it and also no way to enter setup mode. It is then become some sort of
vendor lock-in and has legal concern to the open source software like
grub if it gets signed to prevent from freely distributed. If ARM
provides setup mode and user has the freedom to manipulate on the
firmware stores then I think shim may not be necessary.

> > Am I missing anything?

As time goes by shim has also evolved to do the work than it was
expected originally. Here listed some of related features to consider
when we get rid of shim or the MOK key store it manages. I don't know
ARM folks consider these real issue or not, just for information.

1. Key revocation: To revoke a key in db would require the authenticate
varaible support in linux, I didn't know its status much yet. And also
it means each distro requires to work with vendor to get its variable
signed, compared with shim that each disto could revoke their key
indendently it brings way more complex and overhead in the process.  

2. Some distribution may be using kernel module signing which chains to
the MOK store as it is easier to updat from the OS. 

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.

> 
> 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..

Do you think all vendors and distro will have to use common secure
channel to communicate the key distribution related issues ?

Thanks,
Michael

> 
> /
>     Leif
> 

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

[Ard Biesheuvel]

On Mon, 14 Jan 2019 at 05:58, Michael Chang <mchang@suse.com> wrote:
>
> On Fri, Jan 11, 2019 at 10:58:54AM +0000, 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 <mchang@suse.com>:
> > > >
> > > > Hi,
> > > >
> > > > 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.
>
> It will work as far as it goes. I think part of the reason shim was used
> is that early x86 UEFI Secure Boot shipped without function to disable
> it and also no way to enter setup mode. It is then become some sort of
> vendor lock-in and has legal concern to the open source software like
> grub if it gets signed to prevent from freely distributed. If ARM
> provides setup mode and user has the freedom to manipulate on the
> firmware stores then I think shim may not be necessary.
>
> > > Am I missing anything?
>
> As time goes by shim has also evolved to do the work than it was
> expected originally. Here listed some of related features to consider
> when we get rid of shim or the MOK key store it manages. I don't know
> ARM folks consider these real issue or not, just for information.
>
> 1. Key revocation: To revoke a key in db would require the authenticate
> varaible support in linux, I didn't know its status much yet. And also
> it means each distro requires to work with vendor to get its variable
> signed, compared with shim that each disto could revoke their key
> indendently it brings way more complex and overhead in the process.
>

If the distro's key is in KEK, the distro can sign revocation updates directly.

> 2. Some distribution may be using kernel module signing which chains to
> the MOK store as it is easier to updat from the OS.
>

Pardon my ignorance, but I thought MOK keys were only updatable at
boot time? So why is it easier to update a MOK key than it is to
update db directly?

> 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.

> >
> > 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..
>
> 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.

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

[Michael Chang]

On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel wrote:
> On Mon, 14 Jan 2019 at 05:58, Michael Chang <mchang@suse.com> wrote:
> >
> > On Fri, Jan 11, 2019 at 10:58:54AM +0000, 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 <mchang@suse.com>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > 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.
> >
> > It will work as far as it goes. I think part of the reason shim was used
> > is that early x86 UEFI Secure Boot shipped without function to disable
> > it and also no way to enter setup mode. It is then become some sort of
> > vendor lock-in and has legal concern to the open source software like
> > grub if it gets signed to prevent from freely distributed. If ARM
> > provides setup mode and user has the freedom to manipulate on the
> > firmware stores then I think shim may not be necessary.
> >
> > > > Am I missing anything?
> >
> > As time goes by shim has also evolved to do the work than it was
> > expected originally. Here listed some of related features to consider
> > when we get rid of shim or the MOK key store it manages. I don't know
> > ARM folks consider these real issue or not, just for information.
> >
> > 1. Key revocation: To revoke a key in db would require the authenticate
> > varaible support in linux, I didn't know its status much yet. And also
> > it means each distro requires to work with vendor to get its variable
> > signed, compared with shim that each disto could revoke their key
> > indendently it brings way more complex and overhead in the process.
> >
> 
> If the distro's key is in KEK, the distro can sign revocation updates directly.

Yes. Anyhow it is still new to distro, either to deliver the key to
vendor directly as KEK, or revoke them with authenticate var updates
both would require close collaboration between vendors and distro.

> 
> > 2. Some distribution may be using kernel module signing which chains to
> > the MOK store as it is easier to updat from the OS.
> >
> 
> Pardon my ignorance, but I thought MOK keys were only updatable at
> boot time? So why is it easier to update a MOK key than it is to
> update db directly?

AFAIK, MOK is copied to kernel keyring during boot time so it is
accessible during run time. The point of using MOK is that 3rd party can
just sign their kernel modules and enroll pubilc cert via the shim UI.
It doesn't require them to own any KEK to the firmware.

> 
> > 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?

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. 

> 
> > >
> > > 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..
> >
> > 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, 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.

Thanks,
Michael

> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Alexander Graf]

On 01/14/2019 10:14 AM, Michael Chang wrote:
> On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel wrote:
>> On Mon, 14 Jan 2019 at 05:58, Michael Chang <mchang@suse.com> wrote:
>>> On Fri, Jan 11, 2019 at 10:58:54AM +0000, 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 <mchang@suse.com>:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> 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.
>>> It will work as far as it goes. I think part of the reason shim was used
>>> is that early x86 UEFI Secure Boot shipped without function to disable
>>> it and also no way to enter setup mode. It is then become some sort of
>>> vendor lock-in and has legal concern to the open source software like
>>> grub if it gets signed to prevent from freely distributed. If ARM
>>> provides setup mode and user has the freedom to manipulate on the
>>> firmware stores then I think shim may not be necessary.
>>>
>>>>> Am I missing anything?
>>> As time goes by shim has also evolved to do the work than it was
>>> expected originally. Here listed some of related features to consider
>>> when we get rid of shim or the MOK key store it manages. I don't know
>>> ARM folks consider these real issue or not, just for information.
>>>
>>> 1. Key revocation: To revoke a key in db would require the authenticate
>>> varaible support in linux, I didn't know its status much yet. And also
>>> it means each distro requires to work with vendor to get its variable
>>> signed, compared with shim that each disto could revoke their key
>>> indendently it brings way more complex and overhead in the process.
>>>
>> If the distro's key is in KEK, the distro can sign revocation updates directly.
> Yes. Anyhow it is still new to distro, either to deliver the key to
> vendor directly as KEK, or revoke them with authenticate var updates
> both would require close collaboration between vendors and distro.

If we sign our own grub with the old and new key and then have a grub 
module to revoke the old key once booted with the new key, we should be 
all good, no?

Of course that would require a grub module to do so, but I don't see 
that as a big problem to write?

>
>>> 2. Some distribution may be using kernel module signing which chains to
>>> the MOK store as it is easier to updat from the OS.
>>>
>> Pardon my ignorance, but I thought MOK keys were only updatable at
>> boot time? So why is it easier to update a MOK key than it is to
>> update db directly?
> AFAIK, MOK is copied to kernel keyring during boot time so it is
> accessible during run time. The point of using MOK is that 3rd party can
> just sign their kernel modules and enroll pubilc cert via the shim UI.
> It doesn't require them to own any KEK to the firmware.

Can we have a similar mechanism for modifying the KEK from within grub? 
Then users could add their own keys using that as well.

So all that's needed at that point is to somehow pass the KEK keys to 
the kernel for attestation down the chain. Can we read out the keys from 
grub? Or is there an RTS for it?

>
>>> 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?
>
> 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.

How about we just install grub in the default boot path?

I personally think we really don't need fallback.efi either - it makes 
much more sense to move that functionality into grub if grub is what we 
want to boot anyway.


Alex

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

[Michael Chang]

On Mon, Jan 14, 2019 at 11:22:23AM +0100, Alexander Graf wrote:
> On 01/14/2019 10:14 AM, Michael Chang wrote:
> > On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel wrote:
> > > On Mon, 14 Jan 2019 at 05:58, Michael Chang <mchang@suse.com> wrote:
> > > > On Fri, Jan 11, 2019 at 10:58:54AM +0000, 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 <mchang@suse.com>:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > 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.
> > > > It will work as far as it goes. I think part of the reason shim was used
> > > > is that early x86 UEFI Secure Boot shipped without function to disable
> > > > it and also no way to enter setup mode. It is then become some sort of
> > > > vendor lock-in and has legal concern to the open source software like
> > > > grub if it gets signed to prevent from freely distributed. If ARM
> > > > provides setup mode and user has the freedom to manipulate on the
> > > > firmware stores then I think shim may not be necessary.
> > > > 
> > > > > > Am I missing anything?
> > > > As time goes by shim has also evolved to do the work than it was
> > > > expected originally. Here listed some of related features to consider
> > > > when we get rid of shim or the MOK key store it manages. I don't know
> > > > ARM folks consider these real issue or not, just for information.
> > > > 
> > > > 1. Key revocation: To revoke a key in db would require the authenticate
> > > > varaible support in linux, I didn't know its status much yet. And also
> > > > it means each distro requires to work with vendor to get its variable
> > > > signed, compared with shim that each disto could revoke their key
> > > > indendently it brings way more complex and overhead in the process.
> > > > 
> > > If the distro's key is in KEK, the distro can sign revocation updates directly.
> > Yes. Anyhow it is still new to distro, either to deliver the key to
> > vendor directly as KEK, or revoke them with authenticate var updates
> > both would require close collaboration between vendors and distro.
> 
> If we sign our own grub with the old and new key and then have a grub module
> to revoke the old key once booted with the new key, we should be all good,
> no?

The revoked old key will be added to dbx that will block execution of
image carrying old signatures. I think in this case grub will not be
able to run because of that.

> Of course that would require a grub module to do so, but I don't see that as
> a big problem to write?

I don't know if upstream is still holding any opposition to 'writing to
nvram' from grub. There seems to have patch proposed for that but did
not get merged. From me I don't foresee problem of implementing that
feature to grub.

> 
> > 
> > > > 2. Some distribution may be using kernel module signing which chains to
> > > > the MOK store as it is easier to updat from the OS.
> > > > 
> > > Pardon my ignorance, but I thought MOK keys were only updatable at
> > > boot time? So why is it easier to update a MOK key than it is to
> > > update db directly?
> > AFAIK, MOK is copied to kernel keyring during boot time so it is
> > accessible during run time. The point of using MOK is that 3rd party can
> > just sign their kernel modules and enroll pubilc cert via the shim UI.
> > It doesn't require them to own any KEK to the firmware.
> 
> Can we have a similar mechanism for modifying the KEK from within grub? Then
> users could add their own keys using that as well.

From me it looks promising as the signed variable can be a file and we
implement grub command for writing it (to KEK or db). This operation can
also be done from linux directly as authenticated variable is accessible
through run time service.

It means there's other channel to make 3rd-party key to the firmware. If
the system is shipped with pre-configured keys, and if it has been
signed/trusted by one of the KEK or PK then the process of enrolling is
out-of-box to the user in an automateed manner which can also work with
package update. If not users can also learn the trick of enrolling it
through the firmare's boot menu. It may not be necessary for bootloader
to support that imho.

> 
> So all that's needed at that point is to somehow pass the KEK keys to the
> kernel for attestation down the chain. Can we read out the keys from grub?

I think Yes.

> Or is there an RTS for it?

I thin yes, we can use RTS (Run Time Service) to access KEK and db.

> 
> > 
> > > > 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?
> > 
> > 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.
> 
> How about we just install grub in the default boot path?

If ARM don't consider multiple os boot an issue then certainly it is the
best case to use default boot path.

> I personally think we really don't need fallback.efi either - it makes much
> more sense to move that functionality into grub if grub is what we want to
> boot anyway.

Agreed.

Thanks,
Michael

> 
> 
> Alex
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Peter Jones]

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.

> 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.

-- 
  Peter

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

[Michael Chang]

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

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

[Peter Jones]

On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel 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.

It is a separate binary, but your deployment method here is way off -
the whole point is that it just rebuilds Boot#### entries from the CSV
file in your vendor directory.  Anyway, it's tiny and only tangentially
related to shim - it just happens to be built from the same tree because
that's where I happened to put it.

> > > 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..
> >
> > 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.

On x86 land revocations are distributed by UEFI posting them to their
website, but obviously that's only workable because we have a common
signer.  But it's also only *needed* because we have a common root of
trust in the signing chain.

-- 
  Peter

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

[Alexander Graf]

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 <mchang@suse.com>:
>>>
>>> Hi,
>>>
>>> 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?


Alex

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

[Matthew Garrett]

On Thu, Jan 10, 2019 at 12:59 AM Alexander Graf <agraf@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.

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

[Alexander Graf]

On 11.01.19 20:32, Matthew Garrett wrote:
> On Thu, Jan 10, 2019 at 12:59 AM Alexander Graf <agraf@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?


Alex

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

[Michael Chang]

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 <agraf@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

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 <agraf@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.

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