[edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

[Jeff Brasen via groups.io]

In my opinion MdePkg is where this should be as it is meant to be used by multiple software entities (linux kernel, grub, edk2, coreboot w/ uefi binding) and probably should be documented in some spec (Although, I am not sure which one would make sense)

I am fine with MdeModulePkg as well though.


Thanks,

Jeff

________________________________
From: Ard Biesheuvel <ardb at kernel.org>
Sent: Friday, July 16, 2021 9:56 AM
To: Kinney, Michael D <michael.d.kinney at intel.com>
Cc: Jeff Brasen <jbrasen at nvidia.com>; devel at edk2.groups.io <devel at edk2.groups.io>; ardb+tianocore at kernel.org <ardb+tianocore at kernel.org>; Justen, Jordan L <jordan.l.justen at intel.com>; gaoliming at byosoft.com.cn <gaoliming at byosoft.com.cn>; Liu, Zhiguang <zhiguang.liu at intel.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud at arm.com>
Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

External email: Use caution opening links or attachments


On Fri, 16 Jul 2021 at 17:00, Kinney, Michael D
<michael.d.kinney at intel.com> wrote:
>
> Hi Ard,
>
> I see you were involved in the OS side changes.
>
> Can you explain what is required for the FW <-> OS interface with respect to Load File Protocol and this media device path node.
>
> What happens if this media device path node is not present?  What breaks?
>
> Trying to figure out if this is a required interop feature (MdePkg candidate) or an EDK II specific extension (MdeModulePkg candidate).
>

Let me give some context first:

Linux distro boot generally relies on an initial ramdisk (initrd)
which is provided by the loader, and which contains additional kernel
modules (for storage and netwerk, for instance), and the initial user
space startup code, ie., the code which brings up the user space side
of the entire OS.

Before we introduced this media path, the only way for a EFI pre-OS
loader (such as GRUB) to provide this initrd was to copy it into DRAM
somewhere, and use a arch-specific method of passing the DRAM address
and size to the OS (x86 uses struct bootparam, whereas ARM uses device
tree). It also requires knowledge on the part of GRUB regarding which
parts of DRAM are suitable for holding an initrd image. For measured
boot scenarios, it may be an advantage not to have the initrd linger
in DRAM for longer that necessary, and we actually intend to measure
the initrd loaded via the new method right after it has been loaded
this way.

To avoid extending this to other architectures such as RISC-V, I
decided to introduce a special vendor media path for Linux initrd
images, which GRUB et al can implement, which provides the initrd
image when the OS loader that consumes it asks for it.

So for Linux on x86 or ARM, this is optional, given that support for
the old method is not going away any time soon. For RISC-V, I
suggested that only the new method be implemented, but I am not sure
what the status is there. Note that many embedded style systems don't
use GRUB, and may not use initrds to begin with. OTOH, U-Boot also
implements support for the Linux initrd vendor media path, and work is
ongoing to add measured boot support as well.

In any case, I don't have a strong preference where this should live,
as long as it is in a generic place where all architectures can use
it.

--
Ard.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77977): https://edk2.groups.io/g/devel/message/77977
Mute This Topic: https://groups.io/mt/84231808/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20210720/1b9435be/attachment.htm>