linux-kernel - [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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 19 Mar 2020 16:49:05 -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: [PATCH 1/1] x86 support for the initrd= command line option

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;
 }

-- 
2.17.1