From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
To: devel@edk2.groups.io
Cc: lersek@redhat.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH v2 00/14] Ovmf: use LoadImage/StartImage for loading command line images
Date: Wed, 4 Mar 2020 10:52:19 +0100 [thread overview]
Message-ID: <20200304095233.21046-1-ard.biesheuvel@linaro.org> (raw)
On ArmVirtQemu, we require the kernel passed via the QEMU -kernel option
to have a PE/COFF header and an EFI stub, so that it can be loaded and
started using the LoadImage and StartImage boot services, respectively.
This means that, on builds that enable secure boot or measured boot, the
kernel image gets authenticated and/or measured as well.
On X86, for historical reasons, we never use LoadImage or StartImage, which
means that:
- kernel images are never authenticated or measured,
- calling Exit() from within the boot stub will attempt tp terminate the
calling image, which is likely to end badly.
So instead, split and generalize the code that exists today for ArmVirtQemu,
and wire it up for x86 so that LoadImage and StartImage are used unless
there is a true need for the special Linux boot protocol.
The first 6 patches are only intended to be a refactoring of the existing
code, and should not result in any functional changes for either ArmVirtQemu
or OVMF.
Patch #12 adds the new Linux specific initrd loadfile2 protocol that aims
to simplify initrd loading from Linux when booting via the PE stub.
Patch #13 is optional, and disables the Linux loader fallback on builds that
have secure boot enabled.
Changes since [v1]:
- handle EFI_SECURITY_VIOLATION return codes from gBS->LoadImage inside the
QemuLoadImageLib implementation consistently, instead of propagating it
- change the prototype of QemuStartKernelImage () to take the handle by
reference, allowing the fallback x86 code to reload the image onto a
fresh handle if needed
- add new patch to declare gX86QemuKernelLoadedImageGuid, and make it a
true protocol instead of just a GUID
- drop unnecessary 'wrapper' struct around QEMU_LEGACY_LOADED_IMAGE (#10)
- switch to QemuFwCfgRead32() consistently
- fix numerous other minor style and logic issues pointed out by Laszlo
- add Laszlo's ack to #1, #2, #3, #5, #7, #11 and #14
Code can be found here:
https://github.com/ardbiesheuvel/edk2/tree/ovmf-loadimage-startimage-v1
https://github.com/ardbiesheuvel/edk2/tree/ovmf-loadimage-startimage-v2
[v1] http://mid.mail-archive.com/20200302072936.29221-1-ard.biesheuvel@linaro.org
Ard Biesheuvel (14):
OvmfPkg: add GUID for the QEMU kernel loader fs media device path
OvmfPkg: export abstract QEMU blob filesystem in standalone driver
OvmfPkg: introduce QemuLoadImageLib library class
OvmfPkg: provide a generic implementation of QemuLoadImageLib
ArmVirtPkg: incorporate the new QEMU kernel loader driver and library
ArmVirtPkg/PlatformBootManagerLib: switch to separate QEMU loader
OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line
OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup block
OvmfPkg: create protocol and GUID header for legacy loaded images
OvmfPkg: implement QEMU loader library for X86 with legacy fallback
OvmfPkg: add new QEMU kernel image loader components
OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib
OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device
path
OvmfPkg: use generic QEMU image loader for secure boot enabled builds
ArmVirtPkg/ArmVirtQemu.dsc | 2 +
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 +
.../PlatformBootManagerLib.inf | 9 +-
.../PlatformBootManagerLib/QemuKernel.c | 1061 +----------------
.../Include/Guid/QemuKernelLoaderFsMedia.h | 18 +
OvmfPkg/Include/Library/QemuLoadImageLib.h | 84 ++
.../Protocol/X86QemuKernelLoadedImage.h | 19 +
.../GenericQemuLoadImageLib.c | 278 +++++
.../GenericQemuLoadImageLib.inf | 38 +
.../PlatformBootManagerLib.inf | 2 +-
.../PlatformBootManagerLib/QemuKernel.c | 144 +--
.../X86QemuLoadImageLib/X86QemuLoadImageLib.c | 564 +++++++++
.../X86QemuLoadImageLib.inf | 42 +
OvmfPkg/OvmfPkg.dec | 7 +
OvmfPkg/OvmfPkgIa32.dsc | 6 +
OvmfPkg/OvmfPkgIa32.fdf | 1 +
OvmfPkg/OvmfPkgIa32X64.dsc | 6 +
OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
OvmfPkg/OvmfPkgX64.dsc | 6 +
OvmfPkg/OvmfPkgX64.fdf | 1 +
.../QemuKernelLoaderFsDxe.c | 367 +++---
.../QemuKernelLoaderFsDxe.inf | 50 +
23 files changed, 1315 insertions(+), 1394 deletions(-)
create mode 100644 OvmfPkg/Include/Guid/QemuKernelLoaderFsMedia.h
create mode 100644 OvmfPkg/Include/Library/QemuLoadImageLib.h
create mode 100644 OvmfPkg/Include/Protocol/X86QemuKernelLoadedImage.h
create mode 100644 OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c
create mode 100644 OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
create mode 100644 OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
create mode 100644 OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
copy ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c => OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c (77%)
create mode 100644 OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
--
2.17.1
next reply other threads:[~2020-03-04 9:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 9:52 Ard Biesheuvel [this message]
2020-03-04 9:52 ` [PATCH v2 01/14] OvmfPkg: add GUID for the QEMU kernel loader fs media device path Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 02/14] OvmfPkg: export abstract QEMU blob filesystem in standalone driver Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 03/14] OvmfPkg: introduce QemuLoadImageLib library class Ard Biesheuvel
2020-03-05 9:37 ` [edk2-devel] " Laszlo Ersek
2020-03-05 9:39 ` Laszlo Ersek
2020-03-05 10:22 ` Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 04/14] OvmfPkg: provide a generic implementation of QemuLoadImageLib Ard Biesheuvel
2020-03-05 9:51 ` [edk2-devel] " Laszlo Ersek
2020-03-05 11:29 ` Laszlo Ersek
2020-03-05 11:37 ` Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 05/14] ArmVirtPkg: incorporate the new QEMU kernel loader driver and library Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 06/14] ArmVirtPkg/PlatformBootManagerLib: switch to separate QEMU loader Ard Biesheuvel
2020-03-05 10:01 ` [edk2-devel] " Laszlo Ersek
2020-03-04 9:52 ` [PATCH v2 07/14] OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 08/14] OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup block Ard Biesheuvel
2020-03-05 10:12 ` [edk2-devel] " Laszlo Ersek
2020-03-04 9:52 ` [PATCH v2 09/14] OvmfPkg: create protocol and GUID header for legacy loaded images Ard Biesheuvel
2020-03-05 10:31 ` [edk2-devel] " Laszlo Ersek
2020-03-05 10:40 ` Ard Biesheuvel
2020-03-05 14:29 ` Laszlo Ersek
2020-03-04 9:52 ` [PATCH v2 10/14] OvmfPkg: implement QEMU loader library for X86 with legacy fallback Ard Biesheuvel
2020-03-05 12:33 ` [edk2-devel] " Laszlo Ersek
2020-03-04 9:52 ` [PATCH v2 11/14] OvmfPkg: add new QEMU kernel image loader components Ard Biesheuvel
2020-03-04 9:52 ` [PATCH v2 12/14] OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib Ard Biesheuvel
2020-03-05 12:57 ` [edk2-devel] " Laszlo Ersek
2020-03-04 9:52 ` [PATCH v2 13/14] OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device path Ard Biesheuvel
2020-03-05 13:19 ` Laszlo Ersek
2020-03-04 9:52 ` [PATCH v2 14/14] OvmfPkg: use generic QEMU image loader for secure boot enabled builds Ard Biesheuvel
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-list 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=20200304095233.21046-1-ard.biesheuvel@linaro.org \
--to=devel@edk2.groups.io \
/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