All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Leif Lindholm <leif@nuviainc.com>,
	Peter Jones <pjones@redhat.com>,
	Matthew Garrett <mjg59@google.com>,
	Alexander Graf <agraf@csgraf.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Daniel Kiper <daniel.kiper@oracle.com>
Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems
Date: Fri, 07 Feb 2020 11:54:25 -0800	[thread overview]
Message-ID: <1581105265.4545.17.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAKv+Gu99wxr+OHwqPRjfF136VB3AwPbXXg1tx1=34jF2DU6Z6g@mail.gmail.com>

On Fri, 2020-02-07 at 18:31 +0000, Ard Biesheuvel wrote:
> On Fri, 7 Feb 2020 at 16:20, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Fri, 2020-02-07 at 12:23 +0000, Ard Biesheuvel wrote:
> > > On Fri, 7 Feb 2020 at 09:22, Laszlo Ersek <lersek@redhat.com>
> > > wrote:
> > > > 
> > > > On 02/07/20 10:09, Laszlo Ersek wrote:
> > 
> > [...]
> > > > > For example, virt-install's "--location" option "can
> > > > > recognize certain distribution trees and fetches a bootable
> > > > > kernel/initrd pair to launch the install". It would be nice
> > > > > to keep that working for older distros.
> > > > > 
> > > > > I think LoadFile[2] can co-exist with SimpleFs.
> > > > > 
> > > > > I also think that the "try SimpleFs first, fall back to
> > > > > LoadFile[2] second" requirement applies only to the UEFI boot
> > > > > manager, and not to the kernel's EFI stub. IOW in the new
> > > > > approach the kernel is free to ignore (abandon) the old
> > > > > approach for good.
> > > > 
> > > > ... But that might not be good for compatibility with grub
> > > > and/or the platform firmware, from the kernel's own
> > > > perspective, perhaps?...
> > > > 
> > > > Who is supposed to produce LoadFile2 with the new VenMedia
> > > > devpath?
> > > > 
> > > 
> > > What I am ultimately after is a generic GRUB that uses
> > > LoadImage+Startimage for starting the kernel on all
> > > architectures,
> > 
> > For most boots, we need to pivot to the MoK.  A long time ago, I
> > proposed updating the platform security policy to do an override to
> > allow MoK to become the security verifier (actually principally so
> > I could get the gummiboot bootloader to work with the MoK method):
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/t
> > ree/lib/security_policy.c
> > 
> > And I believe all the pivot bootloaders now do this, but the fear
> > was always this looks a bit like hackery that might not work in
> > some UEFI implementations.  Since we don't really rely on it (shim
> > link loads after signature verification) we don't know whether the
> > assumption does break or not.  We'll need to get much more
> > comfortable with the security override before we can let grub do a
> > simple load+start.
> > 
> 
> I'd like to do something much simpler: let shim override LoadImage
> and StartImage,

Actually, the non-shim bootloaders really don't want to do that: the
whole point of being able to use LoadImage is that you don't need to
know how to load a PECOFF binary or check its signature.  Overriding
the security protocol allows updating the signature check, but if you
look at the current efitools implementation it uses the pkcs7 protocol
to avoid having to include crypto code.

I've got the pecoff code they'd need in my uefi library:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/pecoff.c

But it's a lot of code for things that pride themselves on being tiny.

>  and in their implementations, fall back to the firmware
> ones if necessary.
> 
> > > and is able to load the initrd from anywhere in an arch agnostic
> > > manner.
> > 
> > I think the use case might not really be grub, it's gummiboot, or
> > systemd-boot as its now called:
> > 
> 
> No it is definitely GRUB. GRUB today needs to attach to the shim
> protocol, perform the authentication, measure the payload etc etc,
> which means it knows far too much about the internals of shim or the
> fact that it even exists.

The shim protocol and shim are fairly separate.  I agree it means grub
has to load and know the two entry points for context and verify but
they're very far removed for the inner workings of shim.  Obviously, my
non-shim loader has to supply them for grub, so this is the
implementation:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/shim_protocol.c

It's only 50 lines.

The other thing to consider is that crypto code is huge.  Shim
currently includes it (although it could avoid this by using the pkcs7
verifier protocol trick I use ... I should push that harder) and it
adds about 1M of static code.  Grub does not have this code, so either
grub uses shim and its code to do the signature verification or grub
will have to include the additional 1M as well ... I think using shim
via the protocol is preferable.

> My ideal bootflow would be where the OS installer looks at the
> firmware's db/dbx, doesn't bother to install shim if the OS vendor's
> cert is there, and uses the exact same GRUB regardless of whether
> shim is part of the bootflow or not.

That's not enough.  The whole point of MoK is that the user may have
done their own key addition, so you could be in the situation where the
vendor cert is present in db but the user has a MoK override for boot
and if you assume presence of the vendor cert means you can use
loadimage, this will fail because the MoK cert isn't in db ... unless
you've added the MoK key via the security protocol override.

> One of the things impeding this is the fact that we cannot load the
> initrd from anywhere when using loadimage+startimage.

unless initrd becomes a PECOFF binary, it can never be loaded by
loadimage ... I thought you were still letting the kernel load it via
LoadFile2?  (assuming you are and that the above is just a typo).

James


WARNING: multiple messages have this Message-ID
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Alexander Graf <agraf@csgraf.de>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Matthew Garrett <mjg59@google.com>,
	Peter Jones <pjones@redhat.com>,
	Leif Lindholm <leif@nuviainc.com>,
	Laszlo Ersek <lersek@redhat.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems
Date: Fri, 07 Feb 2020 11:54:25 -0800	[thread overview]
Message-ID: <1581105265.4545.17.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAKv+Gu99wxr+OHwqPRjfF136VB3AwPbXXg1tx1=34jF2DU6Z6g@mail.gmail.com>

On Fri, 2020-02-07 at 18:31 +0000, Ard Biesheuvel wrote:
> On Fri, 7 Feb 2020 at 16:20, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > On Fri, 2020-02-07 at 12:23 +0000, Ard Biesheuvel wrote:
> > > On Fri, 7 Feb 2020 at 09:22, Laszlo Ersek <lersek@redhat.com>
> > > wrote:
> > > > 
> > > > On 02/07/20 10:09, Laszlo Ersek wrote:
> > 
> > [...]
> > > > > For example, virt-install's "--location" option "can
> > > > > recognize certain distribution trees and fetches a bootable
> > > > > kernel/initrd pair to launch the install". It would be nice
> > > > > to keep that working for older distros.
> > > > > 
> > > > > I think LoadFile[2] can co-exist with SimpleFs.
> > > > > 
> > > > > I also think that the "try SimpleFs first, fall back to
> > > > > LoadFile[2] second" requirement applies only to the UEFI boot
> > > > > manager, and not to the kernel's EFI stub. IOW in the new
> > > > > approach the kernel is free to ignore (abandon) the old
> > > > > approach for good.
> > > > 
> > > > ... But that might not be good for compatibility with grub
> > > > and/or the platform firmware, from the kernel's own
> > > > perspective, perhaps?...
> > > > 
> > > > Who is supposed to produce LoadFile2 with the new VenMedia
> > > > devpath?
> > > > 
> > > 
> > > What I am ultimately after is a generic GRUB that uses
> > > LoadImage+Startimage for starting the kernel on all
> > > architectures,
> > 
> > For most boots, we need to pivot to the MoK.  A long time ago, I
> > proposed updating the platform security policy to do an override to
> > allow MoK to become the security verifier (actually principally so
> > I could get the gummiboot bootloader to work with the MoK method):
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/t
> > ree/lib/security_policy.c
> > 
> > And I believe all the pivot bootloaders now do this, but the fear
> > was always this looks a bit like hackery that might not work in
> > some UEFI implementations.  Since we don't really rely on it (shim
> > link loads after signature verification) we don't know whether the
> > assumption does break or not.  We'll need to get much more
> > comfortable with the security override before we can let grub do a
> > simple load+start.
> > 
> 
> I'd like to do something much simpler: let shim override LoadImage
> and StartImage,

Actually, the non-shim bootloaders really don't want to do that: the
whole point of being able to use LoadImage is that you don't need to
know how to load a PECOFF binary or check its signature.  Overriding
the security protocol allows updating the signature check, but if you
look at the current efitools implementation it uses the pkcs7 protocol
to avoid having to include crypto code.

I've got the pecoff code they'd need in my uefi library:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/pecoff.c

But it's a lot of code for things that pride themselves on being tiny.

>  and in their implementations, fall back to the firmware
> ones if necessary.
> 
> > > and is able to load the initrd from anywhere in an arch agnostic
> > > manner.
> > 
> > I think the use case might not really be grub, it's gummiboot, or
> > systemd-boot as its now called:
> > 
> 
> No it is definitely GRUB. GRUB today needs to attach to the shim
> protocol, perform the authentication, measure the payload etc etc,
> which means it knows far too much about the internals of shim or the
> fact that it even exists.

The shim protocol and shim are fairly separate.  I agree it means grub
has to load and know the two entry points for context and verify but
they're very far removed for the inner workings of shim.  Obviously, my
non-shim loader has to supply them for grub, so this is the
implementation:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/shim_protocol.c

It's only 50 lines.

The other thing to consider is that crypto code is huge.  Shim
currently includes it (although it could avoid this by using the pkcs7
verifier protocol trick I use ... I should push that harder) and it
adds about 1M of static code.  Grub does not have this code, so either
grub uses shim and its code to do the signature verification or grub
will have to include the additional 1M as well ... I think using shim
via the protocol is preferable.

> My ideal bootflow would be where the OS installer looks at the
> firmware's db/dbx, doesn't bother to install shim if the OS vendor's
> cert is there, and uses the exact same GRUB regardless of whether
> shim is part of the bootflow or not.

That's not enough.  The whole point of MoK is that the user may have
done their own key addition, so you could be in the situation where the
vendor cert is present in db but the user has a MoK override for boot
and if you assume presence of the vendor cert means you can use
loadimage, this will fail because the MoK cert isn't in db ... unless
you've added the MoK key via the security protocol override.

> One of the things impeding this is the fact that we cannot load the
> initrd from anywhere when using loadimage+startimage.

unless initrd becomes a PECOFF binary, it can never be loaded by
loadimage ... I thought you were still letting the kernel load it via
LoadFile2?  (assuming you are and that the above is just a typo).

James


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-02-07 19:54 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 14:03 Ard Biesheuvel
2020-02-06 14:03 ` Ard Biesheuvel
2020-02-06 14:03 ` [PATCH 1/2] efi/libstub: add support for loading the initrd from a device path Ard Biesheuvel
2020-02-06 14:03   ` Ard Biesheuvel
2020-02-06 18:26   ` Heinrich Schuchardt
2020-02-06 18:26     ` Heinrich Schuchardt
2020-02-06 18:46     ` Ilias Apalodimas
2020-02-06 18:46       ` Ilias Apalodimas
2020-02-06 19:15       ` Heinrich Schuchardt
2020-02-06 19:15         ` Heinrich Schuchardt
2020-02-06 20:09         ` Ilias Apalodimas
2020-02-06 20:09           ` Ilias Apalodimas
2020-02-06 22:49           ` Heinrich Schuchardt
2020-02-06 22:49             ` Heinrich Schuchardt
2020-02-07  7:35             ` Ilias Apalodimas
2020-02-07  7:35               ` Ilias Apalodimas
2020-02-06 22:35     ` Ard Biesheuvel
2020-02-06 22:35       ` Ard Biesheuvel
2020-02-07  0:01       ` Heinrich Schuchardt
2020-02-07  0:01         ` Heinrich Schuchardt
2020-02-07  0:21         ` Ard Biesheuvel
2020-02-07  0:21           ` Ard Biesheuvel
2020-02-07  0:57           ` Heinrich Schuchardt
2020-02-07  0:57             ` Heinrich Schuchardt
2020-02-07  8:12             ` Ard Biesheuvel
2020-02-07  8:12               ` Ard Biesheuvel
2020-02-07 13:30               ` Heinrich Schuchardt
2020-02-07 13:30                 ` Heinrich Schuchardt
2020-02-07 13:58                 ` Ard Biesheuvel
2020-02-07 13:58                   ` Ard Biesheuvel
2020-02-07 14:18                   ` Alexander Graf
2020-02-07 14:18                     ` Alexander Graf
2020-02-07 15:30                     ` Ard Biesheuvel
2020-02-07 15:30                       ` Ard Biesheuvel
2020-02-07 15:35                     ` Heinrich Schuchardt
2020-02-07 15:35                       ` Heinrich Schuchardt
2020-02-07 11:09       ` Laszlo Ersek
2020-02-07 11:09         ` Laszlo Ersek
2020-02-07 11:03     ` Laszlo Ersek
2020-02-07 11:03       ` Laszlo Ersek
2020-02-07  9:48   ` Laszlo Ersek
2020-02-07  9:48     ` Laszlo Ersek
2020-02-07 12:36     ` Ard Biesheuvel
2020-02-07 12:36       ` Ard Biesheuvel
2020-02-10 14:26       ` Laszlo Ersek
2020-02-10 14:26         ` Laszlo Ersek
2020-02-09  6:39   ` Lukas Wunner
2020-02-09 11:35     ` Ard Biesheuvel
2020-02-09 11:35       ` Ard Biesheuvel
2020-02-06 14:03 ` [PATCH 2/2] efi/libstub: take noinitrd cmdline argument into account for devpath initrd Ard Biesheuvel
2020-02-06 14:03   ` Ard Biesheuvel
2020-02-06 18:33   ` Heinrich Schuchardt
2020-02-06 18:33     ` Heinrich Schuchardt
2020-02-06 23:44     ` Ard Biesheuvel
2020-02-06 23:44       ` Ard Biesheuvel
2020-02-12 16:01   ` Peter Jones
2020-02-12 16:01     ` Peter Jones
2020-02-07  9:09 ` [PATCH 0/2] arch-agnostic initrd loading method for EFI systems Laszlo Ersek
2020-02-07  9:09   ` Laszlo Ersek
2020-02-07  9:22   ` Laszlo Ersek
2020-02-07  9:22     ` Laszlo Ersek
2020-02-07 12:23     ` Ard Biesheuvel
2020-02-07 12:23       ` Ard Biesheuvel
2020-02-07 16:20       ` James Bottomley
2020-02-07 16:20         ` James Bottomley
2020-02-07 18:31         ` Ard Biesheuvel
2020-02-07 18:31           ` Ard Biesheuvel
2020-02-07 19:54           ` James Bottomley [this message]
2020-02-07 19:54             ` James Bottomley
2020-02-07 20:03             ` Ard Biesheuvel
2020-02-07 20:03               ` Ard Biesheuvel
2020-02-07 18:45 ` Arvind Sankar
2020-02-07 18:45   ` Arvind Sankar
2020-02-07 19:47   ` Ard Biesheuvel
2020-02-07 19:47     ` Ard Biesheuvel
2020-02-07 20:26     ` Arvind Sankar
2020-02-07 20:26       ` Arvind Sankar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1581105265.4545.17.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=agraf@csgraf.de \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ardb@kernel.org \
    --cc=daniel.kiper@oracle.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=leif@nuviainc.com \
    --cc=lersek@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=pjones@redhat.com \
    --cc=xypron.glpk@gmx.de \
    --subject='Re: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.