Message-ID: <CAP6exYJHgqsNq84DCjgNP=nOjp1Aud9J5JAiEZMXe=+dtm-QGA@mail.gmail.com>
Date:   Thu, 19 Mar 2020 17:50:52 -0700
From:   ron minnich <rminnich@...il.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "maintainer:X86 ARCHITECTURE..." <x86@...nel.org>,
        mjg59@...gle.com,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option

Thanks for looking, but I'm not entirely sure how to parse your answer :-)

In LinuxBoot, we compile Linux into a UEFI driver and load it in
FLASH. It's started by the UEFI driver scheduler, a.k.a DxeCore. In
this case, Linux is both a bootloader (for the Linux or other kernel
it will boot) and Linux is also the thing booted by UEFI. As I
mentioned, we want to avoid writing a UEFI driver just to tell Linux
where to find the initramfs. Further, we want to be able to boot this
kernel and have it use an initramfs provided by a different bootloader
(pxeboot, for example). This flexibility is proving very useful for
companies deploying LinuxBoot today.

I got the idea of using initrd= because u-boot is able to pass that
option to the ARM kernel and the ARM kernel will process it: see,
e.g., the usage in arch/arm/configs/acs5k_defconfig.

Are you saying initrd is reserved for a bootloader to produce it or
consume it? It's certainly not either on ARM: it is in some cases
included in a compiled-in command line, and used by the kernel, just
as we are doing in this patch. The kernel build process produces it,
and the kernel consumes it. All this functionality is there, and all
this patch does it bring it into the x86 kernel with this 6 line
patch.

If, in spite of this usage on ARM, you'd still not rather see a
corresponding usage on x86, how do we get the effect we need here?
Again, we don't want to write UEFI drivers, but we would like some
minimal way to communicate to the kernel where an initramfs is in
memory; and, further, we want it to be the lowest priority option, so
we easily override it. Suggestions on how to do this are welcome.

ron

On Thu, Mar 19, 2020 at 4:57 PM <hpa@...or.com> wrote:
>
> On March 19, 2020 4:49:05 PM PDT, ron minnich <rminnich@...il.com> wrote:
> >In LinuxBoot systems, a kernel and initramfs are loaded into FLASH
> >to replace proprietary firmware/BIOS code. Space being at a premium
> >on some systems, the kernel and initramfs must be place in whatever
> >open corners of the FLASH exist. These corners are not always
> >easily used.
> >
> >For example, on Intel-based UEFI systems, the Management Engine
> >(ME) is given half the FLASH, though it uses very little, as little
> >as 1.25MiB.  Not only is 2.75MiB of an 8MiB part unused; but
> >10.75MiB of a 16MiB part is unused. This space can be recovered by
> >a number of tools, e.g. utk and its tighten_me command, and if
> >Linux can be told where the space is Linux can load an initrd from
> >it.
> >
> >In an ideal case, we would take the space from the ME and add it to
> >a FLASH-based filesystem.  While UEFI does have filesystem-like
> >structures, this recovered space can only be added to its "file
> >system" by rebuilding UEFI from source or writing a UEFI device
> >driver. Both these options are impractical in most cases. The space
> >can only be referenced as a physical address.
> >
> >There is code in the core that allows specification of the initrd
> >as a physical address and size, but it is not supported on all
> >architectures. This patch adds support for initrd= to the x86.
> >
> >For debugging and recovery purposes, if initrd= is present in the
> >command line, other existing initrd sources should still have
> >higher priority. The initramfs in flash might be damaged or
> >broken. Hence, it must still be possible to load a kernel and
> >initramfs with a conventional bootloader, or even load the
> >FLASH-based kernel with a different initramfs; or boot a
> >kernel and let it use the initrd in FLASH.
> >
> >In support of that priority ordering, this patch sets the ramdisk
> >image pointer to phys_initrd_start only if it is not already set;
> >and sets ramdisk_size to phys_initrd_size only if it is not already
> >set.
> >
> >It has been tested extensively in LinuxBoot environments.
> >
> >Signed-off-by: Ronald G. Minnich <rminnich@...il.com>
> >---
> > arch/x86/kernel/setup.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> >diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> >index a74262c71484..1b04ef8ea12d 100644
> >--- a/arch/x86/kernel/setup.c
> >+++ b/arch/x86/kernel/setup.c
> >@@ -237,6 +237,9 @@ static u64 __init get_ramdisk_image(void)
> >
> >     ramdisk_image |= (u64)boot_params.ext_ramdisk_image << 32;
> >
> >+    if (ramdisk_image == 0) {
> >+        ramdisk_image = phys_initrd_start;
> >+    }
> >     return ramdisk_image;
> > }
> > static u64 __init get_ramdisk_size(void)
> >@@ -245,6 +248,9 @@ static u64 __init get_ramdisk_size(void)
> >
> >     ramdisk_size |= (u64)boot_params.ext_ramdisk_size << 32;
> >
> >+    if (ramdisk_size == 0) {
> >+        ramdisk_size = phys_initrd_size;
> >+    }
> >     return ramdisk_size;
> > }
>
> The initrd= option is reserved namespace for the bootloader. It is also worth noting that the x86 boot protocol now allows the bootloader to point to arbitrary chunks of memory for the initrd.
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Powered by blists - more mailing lists