Linux-EFI Archive on lore.kernel.org
 help / color / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	lersek@redhat.com, leif@nuviainc.com, pjones@redhat.com,
	mjg59@google.com, agraf@csgraf.de, ilias.apalodimas@linaro.org,
	xypron.glpk@gmx.de, daniel.kiper@oracle.com,
	nivedita@alum.mit.edu, James.Bottomley@hansenpartnership.com,
	lukas@wunner.de
Subject: [PATCH v2 0/3] arch-agnostic initrd loading method for EFI systems
Date: Sun, 16 Feb 2020 15:11:01 +0100
Message-ID: <20200216141104.21477-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/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

Changes since v1:
- merge vendor media device path type definition with the existing device path
  definitions we already have, and rework the latter slightly to be more easily
  reusable
- use 'dev_path' not 'devpath' consistently
- pass correct FilePath value to LoadFile2 (i.e., the device path pointer that
  was advanced to point to the 'end' node by locate_device_path())
- add kerneldoc comment to efi_load_initrd_dev_path()
- take care to only return EFI_NOT_FOUND from efi_load_initrd_dev_path() if the
  LoadFile2 protocol does not exist on the LINUX_EFI_INITRD_MEDIA_GUID device
  path - this makes the logic whether to fallback to the command line method
  more robust

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
Cc: nivedita@alum.mit.edu
Cc: James.Bottomley@hansenpartnership.com
Cc: lukas@wunner.de

Ard Biesheuvel (3):
  efi/dev-path-parser: Add struct definition for vendor type device path
    nodes
  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/apple-properties.c       |  8 +-
 drivers/firmware/efi/dev-path-parser.c        | 38 ++++----
 drivers/firmware/efi/libstub/arm-stub.c       | 20 ++++-
 .../firmware/efi/libstub/efi-stub-helper.c    | 89 +++++++++++++++++++
 drivers/firmware/efi/libstub/efistub.h        |  5 ++
 drivers/firmware/efi/libstub/x86-stub.c       | 47 ++++++++--
 include/linux/efi.h                           | 49 ++++++----
 7 files changed, 201 insertions(+), 55 deletions(-)

-- 
2.17.1


             reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-16 14:11 Ard Biesheuvel [this message]
2020-02-16 14:11 ` [PATCH v2 1/3] efi/dev-path-parser: Add struct definition for vendor type device path nodes Ard Biesheuvel
2020-02-16 14:11 ` [PATCH v2 2/3] efi/libstub: Add support for loading the initrd from a device path Ard Biesheuvel
2020-02-17  9:15   ` Laszlo Ersek
2020-02-17  9:23     ` Ard Biesheuvel
2020-02-17 10:01       ` Laszlo Ersek
2020-02-17 10:22       ` Ard Biesheuvel
2020-02-17 10:26         ` Laszlo Ersek
2020-02-17 11:09         ` Ilias Apalodimas
2020-02-16 14:11 ` [PATCH v2 3/3] efi/libstub: Take noinitrd cmdline argument into account for devpath initrd Ard Biesheuvel
2020-02-17 19:10 ` [PATCH v2 0/3] arch-agnostic initrd loading method for EFI systems Bhupesh Sharma
2020-02-17 19:23   ` Ard Biesheuvel
2020-02-17 20:07     ` Bhupesh Sharma

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=20200216141104.21477-1-ardb@kernel.org \
    --to=ardb@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=agraf@csgraf.de \
    --cc=daniel.kiper@oracle.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=leif@nuviainc.com \
    --cc=lersek@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mjg59@google.com \
    --cc=nivedita@alum.mit.edu \
    --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

Linux-EFI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-efi/0 linux-efi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-efi linux-efi/ https://lore.kernel.org/linux-efi \
		linux-efi@vger.kernel.org
	public-inbox-index linux-efi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-efi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git