linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: linux-efi <linux-efi@vger.kernel.org>,
	Laszlo Ersek <lersek@redhat.com>,
	Leif Lindholm <leif@nuviainc.com>,
	Peter Jones <pjones@redhat.com>,
	Matthew Garrett <mjg59@google.com>,
	Alexander Graf <agraf@csgraf.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header
Date: Thu, 20 Feb 2020 20:29:37 +0100	[thread overview]
Message-ID: <CAKv+Gu_kTVY41AjMWx_R=UJbuqy9UP62m7CotyEtPC8TfCoHsQ@mail.gmail.com> (raw)
In-Reply-To: <4d921ba6-5a34-4dfc-2a58-588933e995b7@gmx.de>

On Thu, 20 Feb 2020 at 15:56, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
>
>
> On 2/20/20 12:06 PM, Ard Biesheuvel wrote:
> > After having added new ways to load the initrd and the mixed mode kernel,
> > we will need to tell the loader about this, so it can use the new, generic
> > method if supported, and fall back to the existing method(s) otherwise.
> >
> > This is an RFC - if there are better ways to record this in the image
> > somehow, please shout.
>
>
> Hello Ard,
>
> for boot loaders like GRUB I understand that the boot loader could use
> the initrd file path from its scripts to prepare a
> EFI_LOAD_FILE2_PROTOCOL matching the loaded kernel.
>
> I am not sure about the requirements for a firmware.
>
> Up to now the U-Boot UEFI sub-system does not care about initial RAM
> disk images at all. With Ilias suggested patch series U-Boot could offer
> a file from a fixed file location via a EFI_LOAD_FILE2_PROTOCOL.
>
> Is there anything else you expect a firmware like U-Boot or EDK2 to do?
>

It highly depends on the use case. The distros really want GRUB, but
others really don't want GRUB (like Ilias). There are other use cases
we are considering where the initrd load is just a memcpy() from NOR
flash.

Given that the u-boot EFI subsystem was originally conceived to be
able to run GRUB, you might see them as complimentary, but one of the
things I am trying to do is ensure that GRUB is not essential for
booting, even taking things like UEFI secure boot and measure boot
into account. Currently, on x86, these are all tied together in a way
that is hard to extrapolate to other architectures.

      reply	other threads:[~2020-02-20 19:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 11:06 [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header Ard Biesheuvel
2020-02-20 11:06 ` [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers Ard Biesheuvel
2020-02-20 17:28   ` Arvind Sankar
2020-02-20 17:32     ` Ard Biesheuvel
2020-02-20 18:04       ` Arvind Sankar
2020-02-20 18:11         ` Arvind Sankar
2020-02-20 18:14         ` Ard Biesheuvel
2020-02-20 19:33           ` Arvind Sankar
2020-02-20 19:51       ` Arvind Sankar
2020-02-20 21:22         ` Ard Biesheuvel
2020-02-20 22:04           ` Arvind Sankar
2020-02-20 11:06 ` [RFC PATCH 2/3] efi/libstub: Introduce symbolic constants for the stub major/minor version Ard Biesheuvel
2020-02-20 11:06 ` [RFC PATCH 3/3] efi: Bump the Linux EFI stub major version number to #1 Ard Biesheuvel
2020-02-20 13:53 ` [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header Daniel Kiper
2020-02-20 14:55 ` Heinrich Schuchardt
2020-02-20 19:29   ` Ard Biesheuvel [this message]

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='CAKv+Gu_kTVY41AjMWx_R=UJbuqy9UP62m7CotyEtPC8TfCoHsQ@mail.gmail.com' \
    --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=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
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).