linux-hardening - Re: [POC][RFC][PATCH 1/2] mm/x86: Add wildcard * option as memmap=nn*align:name

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]

Date: Wed, 8 May 2024 19:23:57 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Mike Rapoport <rppt@...nel.org>, Kees Cook <keescook@...omium.org>,
 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>, "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Vlastimil Babka <vbabka@...e.cz>, Lorenzo Stoakes <lstoakes@...il.com>,
 linux-mm@...ck.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar
 <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
 <dave.hansen@...ux.intel.com>, x86@...nel.org, "H. Peter Anvin"
 <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, Tony Luck
 <tony.luck@...el.com>, "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
 linux-hardening@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>, Ross
 Zwisler <zwisler@...gle.com>, wklin@...gle.com, Vineeth Remanan Pillai
 <vineeth@...byteword.org>, Joel Fernandes <joel@...lfernandes.org>,
 Suleiman Souhlal <suleiman@...gle.com>, Linus Torvalds
 <torvalds@...uxfoundation.org>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>
Subject: Re: [POC][RFC][PATCH 1/2] mm/x86: Add wildcard * option as
 memmap=nn*align:name

On Mon, 6 May 2024 12:38:32 +0200
Ard Biesheuvel <ardb@...nel.org> wrote:

> The logic in arch/x86/boot/compressed/kaslr.c is now only used by non-EFI boot.
> 
> In general, I am highly skeptical that hopes and prayers are enough to
> prevent the firmware from stepping on such a region, unless this is
> only a best effort thing, and failures are acceptable. For instance,

I would be very happy with just a "best effort" approach. I think
kexec/kdump has the same issue and it hasn't been a problem in practice.

> booting an EFI system with/without an external display attached, or
> with a USB device inserted (without even using it during boot) will
> impact the memory map, to the extent that the E820 table derived from
> it may look different. (EFI tries to keep the runtime regions in the
> same place but the boot-time regions are allocated/freed on demand)

Part of my requirement was that the system is exactly the same (no
changes to hardware or even the kernel).

> 
> So I would strongly urge to address this properly, and work with
> firmware folks to define some kind of protocol for this.

We could possibly add that later, but honesty, that is something that I
doubt would ever happen. You would have to get buy-in from all firmware
stakeholders. I'm not sure if this is a big enough use case for them to
even take a look at it.

The main use case for this work is for pstore to have crash information
of what happened up to the crash. In 99.99% of the time, the firmware
or kaslr will not use the memory that was needed, and you can get very
useful information from the crash info. If the pstore is moved, it
should be able to see that the memory is garbage and just reset it.

Note that we can not use kexec/kdump in the field for various reasons,
and I need a way to reserve memory for several different devices (both
x86 and arm).

-- Steve