linux-kernel - reserve_mem command line option causing a reboot but not by the kernel

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]

Message-ID: <20241006133233.32c8708c@rorschach.local.home>
Date: Sun, 6 Oct 2024 13:32:33 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Mike Rapoport <mike.rapoport@...il.com>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra
 <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Ard
 Biesheuvel <ardb@...nel.org>
Subject: reserve_mem command line option causing a reboot but not by the
 kernel

This is mostly just an FYI,

I upgraded both my server and my workstation to 6.12-rc1 to try out the
new reserve_mem and my persistent trace instance. My server which is a
Dell PowerEdge T430 (bought here: https://www.newegg.com/dell-poweredge-t430-tower/p/2NS-0008-70EW5)
worked flawlessly. I enabled tracing, did a reboot and it contained the
trace on the following bootup. This used the following command line:

  reserve_mem=112M:2097152:trace trace_instance=boot_mapped@...ce,console

Then I tried it out on my workstation. This is a machine I built years
ago. It has an American Megatrends Inc. BIOS (no UEFI). Since it only
has 8 CPUs, I had the command line of:

  reserve_mem=20M:2097152:trace trace_instance=boot_mapped@...ce,console

Rebooted, and right after grub (legacy grub) loaded the kernel, the
machine rebooted again. I removed the "reserve_mem" option, and the
kernel booted fine with the rest of the options.

I started debugging this, but something else happened. When the system
rebooted, I picked an older kernel. But it rebooted too! That is,
booting a kernel without the "reserve_mem" code but the "reserve_mem"
option also had this issue! When installing, I did an "update_grub"
that added the command line to every kernel. It rebooted on any kernel
that had "reserve_mem" as one of the kernel command line options. I
tried kernels down to 6.6.

I then renamed the option in the 6.12-rc1 kernel as "reserve_mm" and
tried again. It booted fine! Although I found that my BIOS on this
machine does not keep memory consistent across reboots so the option is
useless.

The strange thing here is why "reserve_mem" on the kernel command line
causes the machine to reboot? It reboots very early. I even hooked up a
serial and enabled earlyprintk, and it doesn't ever print anything when
the reboot happens.

I'm wondering if this has something to do with legacy grub? Perhaps it
is parsing the kernel command line parameter too and does something
special with "reserve_mem"? My server is using grub2, and so are most
of the other machines I tested on. The ones without grub2 had extlinux,
which worked fine too.

I don't have time to debug further. Maybe I need to look at the legacy
grub code. I just found this interesting and decided to share. Perhaps
someone else might hit this too?

-- Steve