From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: agraf@csgraf.de, xypron.glpk@gmx.de, daniel.kiper@oracle.com,
ilias.apalodimas@linaro.org, mjg59@google.com, pjones@redhat.com,
leif@nuviainc.com, lersek@redhat.com,
Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] arch-agnostic initrd loading method for EFI systems
Date: Thu, 6 Feb 2020 14:03:50 +0000 [thread overview]
Message-ID: <20200206140352.6300-1-ardb@kernel.org> (raw)
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/ardb/linux.git/log/?h=efistub-unification2
An implementation for ArmVirtQemu (OVMF for ARM aka AAVMF) can be found
at https://github.com/ardbiesheuvel/edk2/commits/linux-efi-generic.
The change is for ARM only, but the exact same code could be used on x86.
Cc: lersek@redhat.com
Cc: leif@nuviainc.com
Cc: pjones@redhat.com
Cc: mjg59@google.com
Cc: agraf@csgraf.de
Cc: ilias.apalodimas@linaro.org
Cc: xypron.glpk@gmx.de
Cc: daniel.kiper@oracle.com
Ard Biesheuvel (2):
efi/libstub: add support for loading the initrd from a device path
efi/libstub: take noinitrd cmdline argument into account for devpath
initrd
drivers/firmware/efi/libstub/arm-stub.c | 21 ++++--
.../firmware/efi/libstub/efi-stub-helper.c | 74 +++++++++++++++++++
drivers/firmware/efi/libstub/efistub.h | 13 ++++
drivers/firmware/efi/libstub/x86-stub.c | 51 ++++++++++---
include/linux/efi.h | 1 +
5 files changed, 146 insertions(+), 14 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-02-06 14:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 14:03 Ard Biesheuvel [this message]
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 18:26 ` Heinrich Schuchardt
2020-02-06 18:46 ` Ilias Apalodimas
2020-02-06 19:15 ` Heinrich Schuchardt
2020-02-06 20:09 ` Ilias Apalodimas
2020-02-06 22:49 ` Heinrich Schuchardt
2020-02-07 7:35 ` Ilias Apalodimas
2020-02-06 22:35 ` Ard Biesheuvel
2020-02-07 0:01 ` Heinrich Schuchardt
2020-02-07 0:21 ` Ard Biesheuvel
2020-02-07 0:57 ` Heinrich Schuchardt
2020-02-07 8:12 ` Ard Biesheuvel
2020-02-07 13:30 ` Heinrich Schuchardt
2020-02-07 13:58 ` Ard Biesheuvel
2020-02-07 14:18 ` Alexander Graf
2020-02-07 15:30 ` Ard Biesheuvel
2020-02-07 15:35 ` Heinrich Schuchardt
2020-02-07 11:09 ` Laszlo Ersek
2020-02-07 11:03 ` Laszlo Ersek
2020-02-07 9:48 ` Laszlo Ersek
2020-02-07 12:36 ` Ard Biesheuvel
2020-02-10 14:26 ` Laszlo Ersek
[not found] ` <20200209063907.fcwmwtiz2tjhjmol@wunner.de>
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 18:33 ` Heinrich Schuchardt
2020-02-06 23:44 ` Ard Biesheuvel
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:22 ` Laszlo Ersek
2020-02-07 12:23 ` Ard Biesheuvel
2020-02-07 16:20 ` James Bottomley
2020-02-07 18:31 ` Ard Biesheuvel
2020-02-07 19:54 ` James Bottomley
2020-02-07 20:03 ` Ard Biesheuvel
2020-02-07 18:45 ` Arvind Sankar
2020-02-07 19:47 ` Ard Biesheuvel
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=20200206140352.6300-1-ardb@kernel.org \
--to=ardb@kernel.org \
--cc=agraf@csgraf.de \
--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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).