[PATCH v4] s390/iomem: register initrd as an iomem resource when retain_initrd is set

[PATCH v4] s390/iomem: register initrd as an iomem resource when retain_initrd is set

[Joseph Cathcart]

Currently, /proc/iomem contains no reference to initrd memory, even
when initrd is retained and still held in RAM. This makes the memory
ranges invisible from userspace, and unusable to programs such as
kexec. (A sysfs bin file is created for initrd, but this doesn't
help programs which need the explicit memory ranges)

Add initrd to standard_resources[] unconditionally. Add initrd as a
child of iomem_resources only if retain_initrd is specified.

strstr() could match substrings like "retain_initrd=0" or
"no_retain_initrd", but this is how PPC chose to check for
"retain_initrd" param too. (arch/powerpc/kexec/ranges.c)

Signed-off-by: Joseph Cathcart <josephc@linux.ibm.com>
---
 arch/s390/kernel/setup.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index b60284328fe3..373e54ed7519 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -481,15 +481,22 @@ static struct resource bss_resource = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
+static struct resource initrd_resource = {
+	.name = "initrd",
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+};
+
 static struct resource __initdata *standard_resources[] = {
 	&code_resource,
 	&data_resource,
 	&bss_resource,
+	&initrd_resource,
 };
 
 static void __init setup_resources(void)
 {
 	struct resource *res, *std_res, *sub_res;
+	bool retain_initrd = false;
 	phys_addr_t start, end;
 	int j;
 	u64 i;
@@ -501,6 +508,19 @@ static void __init setup_resources(void)
 	bss_resource.start = __pa_symbol(__bss_start);
 	bss_resource.end = __pa_symbol(__bss_stop) - 1;
 
+	if (IS_ENABLED(CONFIG_BLK_DEV_INITRD)) {
+		unsigned long initrd_addr, initrd_size;
+	
+		if (strstr(boot_command_line, "retain_initrd"))
+			retain_initrd = true;
+		if (retain_initrd && get_physmem_reserved(RR_INITRD, &initrd_addr, &initrd_size)) {
+			initrd_resource.start = initrd_addr;
+			initrd_resource.end = initrd_resource.start + initrd_size - 1;
+		} else {
+			retain_initrd = false;
+		}
+	}
+
 	for_each_mem_range(i, &start, &end) {
 		res = memblock_alloc_or_panic(sizeof(*res), 8);
 		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
@@ -517,6 +537,8 @@ static void __init setup_resources(void)
 
 		for (j = 0; j < ARRAY_SIZE(standard_resources); j++) {
 			std_res = standard_resources[j];
+			if (std_res == &initrd_resource && !retain_initrd)
+				continue;
 			if (std_res->start < res->start ||
 			    std_res->start > res->end)
 				continue;
-- 
2.55.0

base commit: 0f23d56f17fdfc7db69d51f64c8b91bbab947aa9

Re: [PATCH v4] s390/iomem: register initrd as an iomem resource when retain_initrd is set

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Using `strstr()` on `boot_command_line` loosely matches negated parameters like `retain_initrd=0`, creating a severe state desynchronization between the `/proc/iomem` resource tree and actual memory.
--

--- Patch [1]: [PATCH v4] s390/iomem: register initrd as an iomem resource when retain_initrd is set ---
commit 7ecf2fd4332ea230894d369c93eebe76e303f37f
Author: Joseph Cathcart <josephc@linux.ibm.com>

s390/iomem: register initrd as an iomem resource when retain_initrd is set

This commit adds initrd to standard_resources[] and registers it as a child
of iomem_resources if the "retain_initrd" boot parameter is specified, making
the retained initrd memory ranges visible in /proc/iomem.

> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index b60284328fe3d..373e54ed75198 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
[ ... ]
> @@ -501,6 +508,19 @@ static void __init setup_resources(void)
>  	bss_resource.start = __pa_symbol(__bss_start);
>  	bss_resource.end = __pa_symbol(__bss_stop) - 1;
>  
> +	if (IS_ENABLED(CONFIG_BLK_DEV_INITRD)) {
> +		unsigned long initrd_addr, initrd_size;
> +	
> +		if (strstr(boot_command_line, "retain_initrd"))
> +			retain_initrd = true;

[Severity: High]
Does this loose strstr() match create a state desynchronization between
/proc/iomem and actual memory if a user passes a negated parameter like
"retain_initrd=0" or "no_retain_initrd"?

The core kernel's exact parameter parsing in init/initramfs.c will correctly
drop the retain_initrd flag and later free the initrd memory. However, this
strstr() check in setup_resources() will falsely evaluate to true, causing
the physical memory of the initrd to be incorrectly registered as
IORESOURCE_BUSY in /proc/iomem.

Since the actual memory is freed by the general allocator, it will be
overwritten by other kernel structures while still being exported as an
intact initrd to userspace. Could this cause tools that rely on the
/proc/iomem tree, such as kexec-tools, to extract corrupted memory thinking
it is a valid initrd?

Even though the commit message notes that PowerPC uses the same pattern,
does copying this approach into s390 still propagate a concrete bug where
kexec might fail or boot with corrupted ramdisk data?

> +		if (retain_initrd && get_physmem_reserved(RR_INITRD, &initrd_addr, &initrd_size)) {
> +			initrd_resource.start = initrd_addr;
> +			initrd_resource.end = initrd_resource.start + initrd_size - 1;
> +		} else {
> +			retain_initrd = false;
> +		}
> +	}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818175755.3520-1-josephc@linux.ibm.com?part=1