Re: [PATCH v2 0/3] arch-agnostic initrd loading method for EFI systems

[Ard Biesheuvel]

On Mon, 17 Feb 2020 at 20:11, Bhupesh Sharma <bhsharma@xxxxxxxxxx> wrote:
>
> Hi Ard,
>
> On Sun, Feb 16, 2020 at 7:41 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >
> > This series introduces an arch agnostic way of loading the initrd into
> > memory from the EFI stub. This addresses a number of shortcomings that
> > affect the current implementations that exist across architectures:
> >
> > - The initrd=<file> command line option can only load files that reside
> >   on the same file system that the kernel itself was loaded from, which
> >   requires the bootloader or firmware to expose that file system via the
> >   appropriate EFI protocol, which is not always feasible. From the kernel
> >   side, this protocol is problematic since it is incompatible with mixed
> >   mode on x86 (this is due to the fact that some of its methods have
> >   prototypes that are difficult to marshall)
> >
> > - The approach that is ordinarily taken by GRUB is to load the initrd into
> >   memory, and pass it to the kernel proper via the bootparams structure or
> >   via the device tree. This requires the boot loader to have an understanding
> >   of those structures, which are not always set in stone, and of the policies
> >   around where the initrd may be loaded into memory. In the ARM case, it
> >   requires GRUB to modify the hardware description provided by the firmware,
> >   given that the initrd base and offset in memory are passed via the same
> >   data structure. It also creates a time window where the initrd data sits
> >   in memory, and can potentially be corrupted before the kernel is booted.
> >
> > Considering that we will soon have new users of these interfaces (EFI for
> > kvmtool on ARM, RISC-V in u-boot, etc), it makes sense to add a generic
> > interface now, before having another wave of bespoke arch specific code
> > coming in.
> >
> > Another aspect to take into account is that support for UEFI secure boot
> > and measured boot is being taken into the upstream, and being able to
> > rely on the PE entry point for booting any architecture makes the GRUB
> > vs shim story much cleaner, as we should be able to rely on LoadImage
> > and StartImage on all architectures, while retaining the ability to
> > load initrds from anywhere.
> >
> > Note that these patches depend on a fair amount of cleanup work that I
> > am targetting for v5.7. Branch can be found at:
> > https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/log/?h=next
> >
> > A PoC implementation for OVMF and ArmVirtQemu (OVMF for ARM aka AAVMF) can
> > be found at https://github.com/ardbiesheuvel/edk2/commits/linux-efi-generic.
> >
> > A U-Boot implementation is under development as well, and can be found at
> > https://github.com/apalos/u-boot/commits/efi_load_file_8
>

Hello Bhupesh,

> Thanks a lot for the patchset. I am still going through the patchset
> and trying to understand how will it impact
> kexec use-cases, namely:
>
> 1. kexec_load() and kecec_file_load(), use '--initrd=<file>' like
> command line options.
>

These should not be affected at all, since they don't go through the EFI stub.

> 2. We have several kexec based bootloader implementations (for example
> linuxboot, see (a) and (b) below) that replaces specific firmware
> functionality like the UEFI DXE phase with a Linux kernel and runtime
> and find the initrd image (for example, uroot) from that same
> filesystem. So these would need modification(s) similar to the OVMF
> AAVMF and u-boot, right?
>

These changes only affect the interaction between the EFI firmware and
the EFI stub. Anything that relies on the raw x86 boot protocol (jump
to offset 0x0 for 32-bit or offset 0x200 for 64-bit) or the EFI
handover protocol (find the boot offset in the setup header and jump
into the image at the discovered offset) will work as before, although
the EFI handover protocol is something I would like to get rid of at
some point in the future. Kexec typically mimics the handover between
the EFI stub and the kernel, not the EFI firmware and the EFI stub, so
I would not expect kexec to be affected at all by any of this.

In general, the intent is to make kexec idempotent, i.e., to make the
first boot as similar as we can to subsequent kexec boots, which is
why we are pushing back against adding bespoke interfaces to pass ACPI
rsdp pointer, smbios table addresses etc.