linux-kernel - Re: [PATCH v6 0/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up

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

Message-ID: <b0ed328f-c4e5-4e9b-ae4e-5c60703ab376@amazon.com>
Date: Thu, 13 Jun 2024 18:54:12 +0200
From: Alexander Graf <graf@...zon.com>
To: Steven Rostedt <rostedt@...dmis.org>, <linux-kernel@...r.kernel.org>,
	<linux-trace-kernel@...r.kernel.org>
CC: Masami Hiramatsu <mhiramat@...nel.org>, Mark Rutland
	<mark.rutland@....com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>, Vincent Donnefort
	<vdonnefort@...gle.com>, Joel Fernandes <joel@...lfernandes.org>, "Daniel
 Bristot de Oliveira" <bristot@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, <suleiman@...gle.com>, Thomas Gleixner
	<tglx@...utronix.de>, Vineeth Pillai <vineeth@...byteword.org>, Youssef Esmat
	<youssefesmat@...gle.com>, Beau Belgrave <beaub@...ux.microsoft.com>,
	"Baoquan He" <bhe@...hat.com>, Borislav Petkov <bp@...en8.de>, "Paul E.
 McKenney" <paulmck@...nel.org>, David Howells <dhowells@...hat.com>, Mike
 Rapoport <rppt@...nel.org>
Subject: Re: [PATCH v6 0/2] mm/memblock: Add "reserve_mem" to reserved named
 memory at boot up

Hey Steve,

On 13.06.24 17:55, Steven Rostedt wrote:
> Reserve unspecified location of physical memory from kernel command line
>
> Background:
>
> In ChromeOS, we have 1 MB of pstore ramoops reserved so that we can extract
> dmesg output and some other information when a crash happens in the field.
> (This is only done when the user selects "Allow Google to collect data for
>   improving the system"). But there are cases when there's a bug that
> requires more data to be retrieved to figure out what is happening. We would
> like to increase the pstore size, either temporarily, or maybe even
> permanently. The pstore on these devices are at a fixed location in RAM (as
> the RAM is not cleared on soft reboots nor crashes). The location is chosen
> by the BIOS (coreboot) and passed to the kernel via ACPI tables on x86.
> There's a driver that queries for this to initialize the pstore for
> ChromeOS:
>
>    See drivers/platform/chrome/chromeos_pstore.c
>
> Problem:
>
> The problem is that, even though there's a process to change the kernel on
> these systems, and is done regularly to install updates, the firmware is
> updated much less frequently. Choosing the place in RAM also takes special
> care, and may be in a different address for different boards. Updating the
> size via firmware is a large effort and not something that many are willing
> to do for a temporary pstore size change.


(sorry for not commenting on earlier versions, I didn't see v1-v5 in my 
inbox)

Do you have a "real" pstore on these systems that you could store 
non-volatile variables in, such as persistent UEFI variables? If so, you 
could create an actually persistent mapping for your trace pstore even 
across kernel version updates as a general mechanism to create reserved 
memblocks at fixed offsets.


> Requirement:
>
> Need a way to reserve memory that will be at a consistent location for
> every boot, if the kernel and system are the same. Does not need to work
> if rebooting to a different kernel, or if the system can change the
> memory layout between boots.
>
> The reserved memory can not be an hard coded address, as the same kernel /
> command line needs to run on several different machines. The picked memory
> reservation just needs to be the same for a given machine, but may be


With KASLR is enabled, doesn't this approach break too often to be 
reliable enough for the data you want to extract?

Picking up the idea above, with a persistent variable we could even make 
KASLR avoid that reserved pstore region in its search for a viable KASLR 
offset.


Alex




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597