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

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 <[email protected]>

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/[email protected]?part=1