linux-kernel - x86: add phys_initrd_[start,size] as an initrd source

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>] [day] [month] [year] [list]

Message-ID: <CAP6exYKCN3k3YLT9WRFYjhhwYn9D0Dg7ow2-mJKGBCQu5r6QSw@mail.gmail.com>
Date:   Sun, 22 Mar 2020 09:31:47 -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: x86: add phys_initrd_[start,size] as an initrd source

In LinuxBoot systems, a kernel and initramfs are loaded into FLASH
to replace proprietary firmware/BIOS code. In most systems, the initrd
is compiled into the kernel, where space allows. 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.

The initrd code provides two variables, phys_initrd_start
and phys_initrd_size, which can be used to indicate the
location of an initrd, which is in the physical address
space but not compiled in or provided in the bootparams.

For debugging and recovery purposes,
other existing initrd sources should still have
higher priority. The initramfs in FLASH might be damaged or
broken.

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