On Thu, 2018-04-12 at 15:58 +0100, Steve McIntyre wrote:
> [ Note cc to the d-efi list. SB is finally in progress after last
> week's sprint! ]
>
> Very belated, it's time we discussed this.
>
> On Tue, Apr 05, 2016 at 11:17:24AM -0700, Linn Crosetto wrote:
> > Package: grub2
> > Version: 2.02~beta2-36
> > Severity: wishlist
> > Tags: patch
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > The current code in 2.02~beta2-36 will silently fall back to
> > calling
> > ExitBootServices() and booting an unsigned kernel if signature
> > verification
> > fails.
> >
> > As a part of support for UEFI Secure Boot in Debian (820036) change
> > the boot
> > to fail if signature verification fails.
> >
> > I have attached a trivial patch for this change. Thanks!
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQIcBAEBAgAGBQJXBAE0AAoJEF/3aG7d/FTWDh4P/ja6Qa0JRr2bIDj+I+sihFmJ
> > fIHVItLpMEU5hrKnpkRas7GflntzfpEObqUmzPLTRsrA1WobEyZDfNJUOonvEojR
> > atccbvjShxNJIZFCr+W8mGh23+Xv+4VFVJ9f2jd+2sOlmViGyM88rDLOZN69vwIe
> > 9+GbTY6Ha3PifVDwLXvNH0cNiInt8uPbPnFOKwAcwSqFncyq5mfpCroLIqgfR5Dv
> > ImROn7to4iurho3MOidJ0gRJm17mcPjzQAyX/Wh2asSiUMx2cIVrkfcSqoeb6W3L
> > sXytfIwMf3YzY+eLEpsTZDYhmxrJGMa9uQ+Ryg1ZCQI0uI/n3We7cXnukofcM+Of
> > sAtETJvr8SYrF5J/v7XafbEKXr64jV7wEEk97kDA+YGdw7nR1Y0UeX3W3AJCuOeo
> > /KF75oIKJrYbRLymT701RwjArKD2wXYDTzmvnQKiTBc4sPofnr+nJIUOGvZ8Tn8O
> > D/vI8PZKStsZ4cuABkiHEmA3y6zlVtJEkS+OGktNWrugNBJXGWHs6AHGjIIGenTQ
> > 8FPeNrC01DHf+170iV/0PXGLfJKn037y9JSDaZXuZkAsSrqmQENLKzOv9ee4QSsm
> > UmalPiqKkyeZRQna7ZDK+LwB8yf02applIzsQcFuF/RahZdgLhwl42doC7LgjpYI
> > wN0JD88AfHJAuUtwbpxc
> > =fkO9
> > -----END PGP SIGNATURE-----
> > > From 52de74c85ef6a9aca426d9de8f188fe92241aff6 Mon Sep 17 00:00:00
> > > 2001
> >
> > From: Linn Crosetto <linn@hpe.com>
> > Date: Tue, 5 Apr 2016 11:49:05 -0600
> > Subject: [PATCH] Disallow unsigned kernels if UEFI Secure Boot is
> > enabled
> >
> > If UEFI Secure Boot is enabled and kernel signature verification
> > fails, do not
> > boot the kernel. Before this change, if kernel signature
> > verification failed
> > then GRUB would fall back to calling ExitBootServices() and
> > continuing the
> > boot.
> >
> > Patch-Name: linuxefi_disable_sb_fallback.patch
> >
> > Signed-off-by: Linn Crosetto <linn@hpe.com>
> > ---
> > grub-core/loader/i386/linux.c | 8 +++-----
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/grub-core/loader/i386/linux.c b/grub-
> > core/loader/i386/linux.c
> > index 2380642..e2e26dd 100644
> > --- a/grub-core/loader/i386/linux.c
> > +++ b/grub-core/loader/i386/linux.c
> > @@ -696,10 +696,8 @@ grub_cmd_linux (grub_command_t cmd
> > __attribute__ ((unused)),
> > using_linuxefi = 0;
> > if (grub_efi_secure_boot ())
> > {
> > - /* Try linuxefi first, which will require a successful
> > signature check
> > - and then hand over to the kernel without calling
> > ExitBootServices.
> > - If that fails, however, fall back to calling
> > ExitBootServices
> > - ourselves and then booting an unsigned kernel. */
> > + /* linuxefi requires a successful signature check and then
> > hand over
> > + to the kernel without calling ExitBootServices. */
> > grub_dl_t mod;
> > grub_command_t linuxefi_cmd;
> >
> > @@ -721,7 +719,7 @@ grub_cmd_linux (grub_command_t cmd
> > __attribute__ ((unused)),
> > return GRUB_ERR_NONE;
> > }
> > grub_dprintf ("linux", "linuxefi failed (%d)\n",
> > grub_errno);
> > - grub_errno = GRUB_ERR_NONE;
> > + goto fail;
> > }
> > }
> > }
>
> This looks like one way of doing this. Philipp Hahn is suggesting
> that
> we just don't include the "linux" module in our signed grub
> build. That's simpler, but potentially causes problems elsewhere,
> e.g. "it gets a bit nasty to try and dynamically switch between linux
> and linuxefi in live-build". So, let's discuss - we need to agree our
> policy and decide the best mechanism here. Go...!
The issues I see is that until now pretty much everywhere "linux" is
used in grub.cfg.
This can be solved easily, and indeed Philipp has already done it, for
local installations - the problems arise when building images.
At least in live-build (not sure about debootstrap/live-wrapper?),
users can provide their own grub.cfg. Personally I've never seen anyone
use anything but "linux" in the menuentry (eg: Kali [2]).
So I'd need to do something like this [1] in live-build:
sed -i "s|linux\(\s\+/\w\+/vmlinuz\)|linuxefi\1|" \
binary/boot/grub/grub.cfg
sed -i "s|initrd\(\s\+/\w\+/initrd\)|initrdefi\1|" \
binary/boot/grub/grub.cfg
With the risk of randomly breaking with weird user's grub.cfg :-/
I'd really like to make the process as transparent as possible for
users, as there are already enough hoops to jump through as-is to get
secure boot working.
I have been using the patch from this bug in production for about a
year as an alternative in the downstream distro at $work, and it seems
to work fine.
On the other hand, I imagine it's easier to verify that nothing is
broken by removing the "linux" module rather than using this patch. So
there's the other side of the coin.
--
Kind regards,
Luca Boccassi
[1] https://salsa.debian.org/bluca/live-build/commits/linuxefi
[2] http://git.kali.org/gitweb/?p=live-build-config.git;a=blob;f=kali-config/common/bootloaders/grub-pc/grub.cfgAttachment:
signature.asc
Description: This is a digitally signed message part