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

[Daniel Schaefer]

On 7/16/21 11:56 PM, Ard Biesheuvel wrote:
> 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.

It's a good idea. We followed your advice and added your initrd command 
to our development branch of RISC-V EDK2:

https://github.com/riscv/riscv-edk2-platforms/commit/534eeba0ac9b984eedc58ba1e8a2d28e2827ba40

And we're using it in our CI to test whether Linux boots:

https://github.com/riscv/riscv-edk2-platforms/blob/riscv-virt-gh-actions/.github/workflows/riscv-edk2.yml#L314

> 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.
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78011): https://edk2.groups.io/g/devel/message/78011
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]
-=-=-=-=-=-=-=-=-=-=-=-