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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c90c574-5cfa-40cf-bd4c-1188136cd886@amazon.com>
Date: Mon, 17 Jun 2024 09:07:29 +0200
From: Alexander Graf <graf@...zon.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: <linux-kernel@...r.kernel.org>, <linux-trace-kernel@...r.kernel.org>,
	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>, Ard Biesheuvel <ardb@...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 19:12, Steven Rostedt wrote:
> On Thu, 13 Jun 2024 18:54:12 +0200
> Alexander Graf <graf@...zon.com> wrote:
>
>> 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.
> After implementing all this, I don't think I can use pstore for my
> purpose. pstore is a generic interface for persistent storage, and
> requires an interface to access it. From what I understand, it's not
> the place to just ask for an area of RAM.
>
> For this, I have a single patch that allows the tracing instance to use
> an area reserved by reserve_mem.
>
>    reserve_mem=12M:4096:trace trace_instance=boot_mapped@...ce
>
> I've already tested this on qemu and a couple of chromebooks. It works
> well.


I believe we're talking about 2 different things :). Let me rephrase a 
bit and make a concrete example.

Imagine you have passed the "reserve_mem=12M:4096:trace" kernel command 
line option. The kernel now comes up and allocates a random chunk of 
memory that - by (admittedly good) chance - may be at the same physical 
location as before. Let's assume it deemed 0x1000000 as a good offset.

Let's now assume you're running on a UEFI system. There, you always have 
non-volatile storage available to you even in the pre-boot phase. That 
means the kernel could create a UEFI variable that says "12M:4096:trace 
-> 0x1000000". The pre-boot phase takes all these UEFI variables and 
marks them as reserved. When you finally reach your command line parsing 
logic for reserve_mem=, you can flip all reservations that were not on 
the command line back to normal memory.

That way you have pretty much guaranteed persistent memory regions, even 
with KASLR changing your memory layout across boots.

The nice thing is that the above is an extension of what you've already 
built: Systems with UEFI simply get better guarantees that their regions 
persist.


>
>>
>>> 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.
> I think I was hit by it once in all my testing. For our use case, the
> few times it fails to map is not going to affect what we need this for
> at all.


Once is pretty good. Do you know why? Also once out of how many runs? Is 
the randomness source not as random as it should be or are the number of 
bits for KASLR maybe so few on your target architecture that the odds of 
hitting anything become low? Do these same constraints hold true outside 
of your testing environment?


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