Linux-EFI Archive on lore.kernel.org
 help / color / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	lersek@redhat.com, leif@nuviainc.com, pjones@redhat.com,
	mjg59@google.com, agraf@csgraf.de, daniel.kiper@oracle.com,
	hdegoede@redhat.com, nivedita@alum.mit.edu,
	mbrown@fensystems.co.uk, mingo@kernel.org
Subject: Re: [RFC PATCH 0/3] efi/x86: add support for generic EFI mixed mode boot
Date: Thu, 13 Feb 2020 12:53:18 -0500
Message-ID: <20200213175317.GC1400002@rani.riverdale.lan> (raw)
In-Reply-To: <20200213145928.7047-1-ardb@kernel.org>

On Thu, Feb 13, 2020 at 03:59:25PM +0100, Ard Biesheuvel wrote:
> This series is another part of my effort to reduce the level of knowledge
> on the part of the bootloader or firmware of internal per-architecture
> details regarding where/how the kernel is loaded and where its initrd and
> other context data are passed.
> 
> The x86 architecture has a so-called 'EFI handover protocol', which defines
> how the bootparams struct should be populated, and how it should be
> interpreted to figure out where to load the kernel, and at which offset in
> the binary the entrypoint is located. This scheme allows the initrd to be
> loaded beforehand, and allows 32-bit firmware to invoke a 64-bit kernel
> via a special entrypoint that manages the state transitions between the
> two execution modes.
> 
> Due to this, x86 loaders currently do not rely on LoadImage and StartImage,
> and therefore, are forced to re-implement things like image authentication
> for secure boot and taking the measurements for measured boot in their open
> coded clones of these routines.
> 
> My previous series on this topic [0] implements a generic way to load the
> initrd from any source supported by the loader without relying on something
> like device trees or bootparams structures, and so native boot should not
> need the EFI handover protocol anymore after those change are merged.
> 
> What remains is mixed mode boot, which also needs the EFI handover protocol
> regardless of whether an initrd is loaded or not. So let's get rid of that
> requirement, and take advantage of the fact that EDK2 based firmware does
> support LoadImage() for X64 binaries on IA32 firmware, which means we can
> rely on the secure boot and measured boot checks being performed by the
> firmware. The only thing we need to put on top is a way to discover the
> non-native entrypoint into the binary in a way that does not rely on x86
> specific headers and data structures.
> 
> So let's introduce a new .compat header in the PE/COFF metadata of the
> bzImage, and populate it with a <machine type, entrypoint> tuple, allowing
> a generic EFI loader to decide whether the entrypoint supports its native
> machine type, and invoke it as an ordinary EFI application entrypoint.
> Since we will not be passing a bootparams structure, we need to discover
> the base of the image (which contains the setup header) via the loaded
> image protocol before we can enter the kernel in 32-bit mode at startup_32()
> 
> A loader implementation for OVMF can be found at [1]. Note that this loader
> code is fully generic, and could be used without modifications if other
> architectures ever emerge that support kernels that can be invoked from a
> non-native (but cross-type supported) loader.
> 
> [0] https://lore.kernel.org/linux-arm-kernel/20200206140352.6300-1-ardb@kernel.org/
> [1] https://github.com/ardbiesheuvel/edk2/commits/linux-efi-generic
> 

As an alternative to the new section, how about having a CONFIG option
to emit the 64-bit kernel with a 32-bit PE header instead, which would
point to efi32_pe_entry? In that case it could be directly loaded by
existing firmware already. You could even have a tool that can mangle an
existing bzImage's header from 64-bit to 32-bit, say using the newly
added kernel_info structure to record the existence and location of
efi32_pe_entry.

Also, the PE header can live anywhere inside the image, right? Is there
any reason to struggle to shoehorn it into the "boot sector"?

  parent reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 14:59 Ard Biesheuvel
2020-02-13 14:59 ` [RFC PATCH 1/3] efi/x86: drop redundant .bss section Ard Biesheuvel
2020-02-13 14:59 ` [RFC PATCH 2/3] efi/x86: add true mixed mode entry point into .compat section Ard Biesheuvel
2020-02-13 16:59   ` Arvind Sankar
2020-02-13 17:13     ` Ard Biesheuvel
2020-02-13 14:59 ` [RFC PATCH 3/3] efi/x86: implement mixed mode boot without the handover protocol Ard Biesheuvel
2020-02-13 17:23   ` Arvind Sankar
2020-02-13 17:42     ` Ard Biesheuvel
2020-02-13 17:53 ` Arvind Sankar [this message]
2020-02-13 17:55   ` [RFC PATCH 0/3] efi/x86: add support for generic EFI mixed mode boot Ard Biesheuvel
2020-02-13 18:47     ` Arvind Sankar
2020-02-13 22:36       ` Ard Biesheuvel
2020-02-14  0:10         ` Arvind Sankar
2020-02-14  0:12           ` Arvind Sankar
2020-02-14  0:21             ` Ard Biesheuvel
2020-02-14  0:38               ` Arvind Sankar

Reply instructions:

You may reply publically 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=20200213175317.GC1400002@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=agraf@csgraf.de \
    --cc=ardb@kernel.org \
    --cc=daniel.kiper@oracle.com \
    --cc=hdegoede@redhat.com \
    --cc=leif@nuviainc.com \
    --cc=lersek@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=mbrown@fensystems.co.uk \
    --cc=mingo@kernel.org \
    --cc=mjg59@google.com \
    --cc=pjones@redhat.com \
    /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