linux-kernel - Re: [PATCH 1/1] x86 support for the initrd= command line option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Mar 2020 09:19:01 -0700
From:   ron minnich <rminnich@...il.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     "H. Peter Anvin" <hpa@...or.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "maintainer:X86 ARCHITECTURE..." <x86@...nel.org>,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option

Subject: [PATCH 1/1] initrdmem= option to specify initrd physical address

This patch adds the initrdmem option:
initrdmem=ss[KMG],nn[KMG]
which is used to specify the physical address of the initrd,
almost always an address in FLASH. It also adds code for
x86 to use the existing phys_init_start and
phys_init_size variables in the kernel.
This is useful in cases where we wish to place a kernel
and initrd in FLASH, but there is no firmware file
system structure in the FLASH.

One such situation occurs when we have reclaimed unused FLASH
space on UEFI systems by, e.g., taking it from the Management
Engine. For example, on many systems, the ME is given half the
FLASH part; not only is 2.75M of an 8M part unused; but 10.75M
of a 16M part is unused. We can use this space to contain
an initrd, but need to tell Linux where it is.

This space is "raw": due to, e.g., UEFI limitations:
it can not be added to UEFI firmware volumes without rebuilding
UEFI from source or writing a UEFI device driver. We can reference it
only as a physical address and size.

At the same time, should we netboot a kernel or load it from
GRUB or syslinux, we want to have the option of not using
the physical address specification. Then, should we wish, it
is easy to boot the kernel and provide an initrd; or boot the
the kernel and let it use the initrd in FLASH. In practice this
has proven to be very helpful as we integrate Linux into FLASH
on x86.

Hence, the most flexible and convenient path is to enable the
initrdmem command line flag in a way that it is the last choice tried.

For example, on the DigitalLoggers Atomic Pi, we burn an image into
FLASH with a built-in command line which includes:
initrdmem=0xff968000,0x200000
which specifies a location and size.

Signed-off-by: Ronald G. Minnich <rminnich@...il.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  7 +++++++
 arch/x86/kernel/setup.c                         |  6 ++++++
 init/do_mounts_initrd.c                         | 13 ++++++++++++-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index c07815d230bc..9cd356958a7f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1714,6 +1714,13 @@

     initrd=        [BOOT] Specify the location of the initial ramdisk

+    initrdmem=    [KNL] Specify a physical adddress and size from which
+            to load the initrd. If an initrd is compiled in or
+            specified in the bootparams, it takes priority
+            over this setting.
+            Format: ss[KMG],nn[KMG]
+            Default is 0, 0
+
     init_on_alloc=    [MM] Fill newly allocated pages and heap objects with
             zeroes.
             Format: 0 | 1
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;
 }

diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
index dab8b1151b56..d72beda824aa 100644
--- a/init/do_mounts_initrd.c
+++ b/init/do_mounts_initrd.c
@@ -28,7 +28,7 @@ static int __init no_initrd(char *str)

 __setup("noinitrd", no_initrd);

-static int __init early_initrd(char *p)
+static int __init early_initrdmem(char *p)
 {
     phys_addr_t start;
     unsigned long size;
@@ -43,6 +43,17 @@ static int __init early_initrd(char *p)
     }
     return 0;
 }
+early_param("initrdmem", early_initrdmem);
+
+/*
+ * This is here as the initrd keyword has been in use since 11/2018
+ * on ARM, PowerPC, and MIPS.
+ * It should not be; it is reserved for bootloaders.
+ */
+static int __init early_initrd(char *p)
+{
+    return early_initrdmem(p);
+}
 early_param("initrd", early_initrd);

 static int init_linuxrc(struct subprocess_info *info, struct cred *new)
-- 
2.17.1