linux-hardening - Re: [PATCH v2 1/2] tracing: ring-buffer: Have the ring buffer code do the vmap of physical memory

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: <Z-u4Tzz9J8hSk6G7@kernel.org>
Date: Tue, 1 Apr 2025 12:56:31 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Steven Rostedt <rostedt@...dmis.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>,
	Vincent Donnefort <vdonnefort@...gle.com>,
	Vlastimil Babka <vbabka@...e.cz>, Kees Cook <kees@...nel.org>,
	Tony Luck <tony.luck@...el.com>,
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 1/2] tracing: ring-buffer: Have the ring buffer code
 do the vmap of physical memory

On Mon, Mar 31, 2025 at 02:42:38PM -0700, Linus Torvalds wrote:
> On Mon, 31 Mar 2025 at 13:57, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > Note, this only works with RAM.
> 
> That's not the issue, actually.
> 
> The issue is whether there's a 'struct page'. And "being RAM" does not
> mean that a struct page exists.
> 
> For example, using "mem=" on the kernel command line will literally
> limit the amount of RAM the kernel will use, and in doing so will
> limit the page allocations too.

And using memmap=m$n on x86 creates a hole in System RAM that does not have
neither struct page nor kernel mappings and it is never considered RAM
anywhere in mm.
 
> IOW, all of these kernel command line things are *subtle*.
> 
> Don't mis-use them by then making assumptions about how they work
> today (or how they will work tomorrow).

I'd say it's better not to use them at all. They cause weirdness in memory
layout and also they are inconsistent in how architectures implement them.
 
> > Mike can correct me if I'm wrong, but the memory that was stolen was actual
> > memory returned by the system (E820 in x86). It reserves the memory before
> > the memory allocation reserves this memory. So what reserve_mem returns is
> > valid memory that can be used by memory allocator, but is currently just
> > "reserved" which means it wants to prevent the allocator from using it.
> 
> That may indeed be true of reserve_mem.

The reserve_mem behaves like any other early allocation, it has proper
struct pages (PG_Reserved) and it is mapped in the direct map so
phys_to_virt() will work on it.

As for mapping it to userspace, vm_iomap_memory() seems the best API to
use. It has all the alignment checks and will refuse to map ranges that are
not properly aligned and it will use vma information to create the right
mappings.
 
>                Linus

-- 
Sincerely yours,
Mike.