Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 19 Mar 2020 17:59:16 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <CAP6exYJHgqsNq84DCjgNP=nOjp1Aud9J5JAiEZMXe=+dtm-QGA@mail.gmail.com>
References: <CAP6exY+LnUXaOVRZUXmi2wajCPZoJVMFFAwbCzN3YywWyhi8ZA@mail.gmail.com> <D31718CF-1755-4846-8043-6E62D57E4937@zytor.com> <CAP6exYJHgqsNq84DCjgNP=nOjp1Aud9J5JAiEZMXe=+dtm-QGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option
To:     ron minnich <rminnich@gmail.com>
CC:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "maintainer:X86 ARCHITECTURE..." <x86@kernel.org>,
        mjg59@google.com,
        lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
From:   hpa@zytor.com
Message-ID: <8E80838A-7A3F-4600-AF58-923EDA3DE91D@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On March 19, 2020 5:50:52 PM PDT, ron minnich <rminnich@gmail=2Ecom> wrote:
>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=2E It's started by the UEFI driver scheduler, a=2Ek=2Ea DxeCore=2E =
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=2E As I
>mentioned, we want to avoid writing a UEFI driver just to tell Linux
>where to find the initramfs=2E Further, we want to be able to boot this
>kernel and have it use an initramfs provided by a different bootloader
>(pxeboot, for example)=2E This flexibility is proving very useful for
>companies deploying LinuxBoot today=2E
>
>I got the idea of using initrd=3D because u-boot is able to pass that
>option to the ARM kernel and the ARM kernel will process it: see,
>e=2Eg=2E, the usage in arch/arm/configs/acs5k_defconfig=2E
>
>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=2E The kernel build process produces it,
>and the kernel consumes it=2E All this functionality is there, and all
>this patch does it bring it into the x86 kernel with this 6 line
>patch=2E
>
>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=2E Suggestions on how to do this are welcome=2E
>
>ron
>
>On Thu, Mar 19, 2020 at 4:57 PM <hpa@zytor=2Ecom> wrote:
>>
>> On March 19, 2020 4:49:05 PM PDT, ron minnich <rminnich@gmail=2Ecom>
>wrote:
>> >In LinuxBoot systems, a kernel and initramfs are loaded into FLASH
>> >to replace proprietary firmware/BIOS code=2E Space being at a premium
>> >on some systems, the kernel and initramfs must be place in whatever
>> >open corners of the FLASH exist=2E These corners are not always
>> >easily used=2E
>> >
>> >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=2E25MiB=2E  Not only is 2=2E75MiB of an 8MiB part unused; but
>> >10=2E75MiB of a 16MiB part is unused=2E This space can be recovered by
>> >a number of tools, e=2Eg=2E utk and its tighten_me command, and if
>> >Linux can be told where the space is Linux can load an initrd from
>> >it=2E
>> >
>> >In an ideal case, we would take the space from the ME and add it to
>> >a FLASH-based filesystem=2E  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=2E Both these options are impractical in most cases=2E The spac=
e
>> >can only be referenced as a physical address=2E
>> >
>> >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=2E This patch adds support for initrd=3D to the x86=2E
>> >
>> >For debugging and recovery purposes, if initrd=3D is present in the
>> >command line, other existing initrd sources should still have
>> >higher priority=2E The initramfs in flash might be damaged or
>> >broken=2E 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=2E
>> >
>> >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=2E
>> >
>> >It has been tested extensively in LinuxBoot environments=2E
>> >
>> >Signed-off-by: Ronald G=2E Minnich <rminnich@gmail=2Ecom>
>> >---
>> > arch/x86/kernel/setup=2Ec | 6 ++++++
>> > 1 file changed, 6 insertions(+)
>> >
>> >diff --git a/arch/x86/kernel/setup=2Ec b/arch/x86/kernel/setup=2Ec
>> >index a74262c71484=2E=2E1b04ef8ea12d 100644
>> >--- a/arch/x86/kernel/setup=2Ec
>> >+++ b/arch/x86/kernel/setup=2Ec
>> >@@ -237,6 +237,9 @@ static u64 __init get_ramdisk_image(void)
>> >
>> >     ramdisk_image |=3D (u64)boot_params=2Eext_ramdisk_image << 32;
>> >
>> >+    if (ramdisk_image =3D=3D 0) {
>> >+        ramdisk_image =3D 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 |=3D (u64)boot_params=2Eext_ramdisk_size << 32;
>> >
>> >+    if (ramdisk_size =3D=3D 0) {
>> >+        ramdisk_size =3D phys_initrd_size;
>> >+    }
>> >     return ramdisk_size;
>> > }
>>
>> The initrd=3D option is reserved namespace for the bootloader=2E It is
>also worth noting that the x86 boot protocol now allows the bootloader
>to point to arbitrary chunks of memory for the initrd=2E
>> --
>> Sent from my Android device with K-9 Mail=2E Please excuse my brevity=
=2E

It has been designated consumed by the bootloader on x86 since at least 19=
95=2E So ARM broke it=2E

How is this information passed to any version of Linux in the first place,=
 and how do you then start up Linux? I suspect this is probably rather simp=
le in the end=2E=2E=2E

Note that when Linux is run as an UEFI binary the kernel UEFI stub can loa=
d an initrd file via the UEFI file I/O interface=2E

In some ways, arguably the Right Thing for the firmware to expose this wou=
ld be to have a resource exposed via ACPI =2E


--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E