On Tue, 8 Aug 2023 at 17:34, Dimitri John Ledkov
<dimitri.led...@canonical.com> wrote:
>
> On Mon, 7 Aug 2023, 13:23 Ard Biesheuvel, <a...@kernel.org> wrote:
> >
> > Recent mixed-mode Linux kernels (i.e., v4.0 or newer) can access EFI
> > runtime services at OS runtime even when the OS was not entered via the
> > EFI stub. This is because, instead of reverting back to the firmware's
> > segment selectors, GDTs and IDTs, the 64-bit kernel simply calls 32-bit
> > runtime services using compatilibity mode (i.e., the same mode used for
> > 32-bit user space) without taking down all interrupt handling, exception
> > handling etc.
> >
> > This means that GRUB's legacy x86 boot mode is sufficient to make use of
> > this: 32-bit i686 builds of GRUB can already boot 64-bit kernels in EFI
> > enlightened mode (but without going via the EFI stub), and provide all
> > the metadata that the OS needs to map the EFI runtime regions and call
> > EFI runtime services successfully.
>
> I'm not sure I understand the target combination here, and I'm not
> sure we want to support it.
>
The point is not what we /want/ to support - it is what we already
supported in the past, and the recent EFI changes result in
regressions for those scenarios.
> For now, we keep shipping both 32bit and 64bit x86 revocations
> together. However, the time will come that we will want or need to
> drop the 32bit revocations. Ubuntu has never signed a 32bit build of
> grub for secureboot, nor have we ever signed 32bit kernels to boot
> either. Most distributions have also stopped 32bit x86 builds, and/or
> don't support them to the same feature level (there are some that
> enable lots of combinations, i.e. debian, but even there i am not sure
> such hardware exists).
>
> I see this as a bug that 32-bit i686 build of Grub can launch 64-bit
> kernels - potentially without using shim / shim-lock / sbat
> verification.
>
A 32-bit *EFI* build of GRUB, which you will never be able to boot on
anything other than 32-bit EFI, i.e., systems that nobody cares about
wrt secure boot.
> I would feel much better if under shim-lock/secureboot only matching
> bitness was allowed to be booted and supported. Meaning no mixing &
> matching i686 grub builds launching x86_64 kernels, or vice versa, and
> ditoo on any other arches too (i.e. no mixing between
> riscv32/riscv64/riscv128, nor armhf/arm64).
>
AFAICT, the non-EFIstub x86 boot path in GRUB has always supported
booting kernels of any bitness (provided, of course, that the CPU is
long mode capable)
With adding the EFI support, we broke this which may potentially harm users.
> I am impressed it is technologically possible, but do we really want
> to implement/design/support/encourage that?
>
Distros already do, that is the whole point. It is called mixed mode,
and it is something I am trying to get rid of.
The current mixed-mode implementation has elaborate plumbing so that
the 64-bit EFI stub can make use of 32-bit boot services. This was
presented to me in the past as a prerequisite for being able to
support mixed mode (and therefore a justification for upstreaming the
EFI handover protocol). However, I realized that the current mixed
mode support in Linux does not actually rely on this: the only thing
you need is a bootloader that implements the x86 Linux boot protocol
directly but also passes EFI memory map, system table, etc. GRUB
already did this. IOW, mainline i386-efi GRUB already supported mixed
mode, and the recent EFI changes broke that.
> I'm not even sure if 32-bit x86 EFI grub platform even makes sense
> anymore, and maybe it should be ripped out altogether? and leave i686
> boot to pc-bios only. i686 EFI was a short lived experiment that died
> without ever taking off.
>
Not for mixed-mode - i.e., 'netbooks' with 64-bit Atom CPUs that
shipped with 32-bit Windows and therefore 32-bit EFI. Not sure how
many are still in circulation running Linux.
Ideally, we'd drop this altogether. However, by making this change,
which is arguably a regression fix, we can phase out the EFI stub part
of mixed mode, and only retain the EFI runtime support.
> >
> > It does mean that GRUB should not attempt to invoke the firmware's
> > LoadImage/StartImage methods on kernel builds that it knows cannot be
> > started natively. So add a check for this in the native EFI boot path,
> > and fall back to legacy x86 mode in such cases.
> >
> > Note that in the general case, booting non-native images of the same
> > native word size (e.g., X64 EFI apps on arm64 firmware) might be
> > supported by means of emulation, so let's only disallow images that use
> > a non-native word size. This will also permit booting i686 kernels on
> > x86_64 builds, although without access to runtime services, as this is
> > not supported by Linux.
> >
> > This change on top of 2.12-rc1 is sufficient to boot ordinary Linux
> > mixed mode builds and get full access to the EFI runtime services.
> >
> > Cc: Daniel Kiper <daniel.ki...@oracle.com>
> > Cc: Steve McIntyre <st...@einval.com>
> > Cc: Julian Andres Klode <julian.kl...@canonical.com>
> > Signed-off-by: Ard Biesheuvel <a...@kernel.org>
> > ---
> > grub-core/loader/efi/linux.c | 5 +++++
> > include/grub/efi/pe32.h | 6 ++++++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/grub-core/loader/efi/linux.c b/grub-core/loader/efi/linux.c
> > index ed325f2b0aae2d6f..1d0734e295043df7 100644
> > --- a/grub-core/loader/efi/linux.c
> > +++ b/grub-core/loader/efi/linux.c
> > @@ -120,6 +120,11 @@ grub_arch_efi_linux_load_image_header (grub_file_t
> > file,
> > return grub_error (GRUB_ERR_FILE_READ_ERROR, "failed to read COFF
> > image header");
> > }
> >
> > + if (lh->pe_image_header.optional_header.magic != GRUB_PE32_NATIVE_MAGIC)
> > + {
> > + return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "non-native image
> > not supported");
> > + }
> > +
> > /*
> > * Linux kernels built for any architecture are guaranteed to support the
> > * LoadFile2 based initrd loading protocol if the image version is >= 1.
> > diff --git a/include/grub/efi/pe32.h b/include/grub/efi/pe32.h
> > index 101859af1ea64237..4e6e9d254bd35c9b 100644
> > --- a/include/grub/efi/pe32.h
> > +++ b/include/grub/efi/pe32.h
> > @@ -267,6 +267,12 @@ struct grub_pe32_section_table
> >
> > #define GRUB_PE32_SIGNATURE_SIZE 4
> >
> > +#if GRUB_TARGET_SIZEOF_VOID_P == 8
> > +#define GRUB_PE32_NATIVE_MAGIC GRUB_PE32_PE64_MAGIC
> > +#else
> > +#define GRUB_PE32_NATIVE_MAGIC GRUB_PE32_PE32_MAGIC
> > +#endif
> > +
> > struct grub_pe_image_header
> > {
> > /* This is always PE\0\0. */
> > --
> > 2.39.2
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
