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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHk-=wjQ=ZY5K+tSF1xui3aoL2Vkzsvp8W1mQ9iVeTQ9Cnbc7Q@mail.gmail.com>
Date: Mon, 31 Mar 2025 17:27:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
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>, Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, 
	Kees Cook <kees@...nel.org>, Tony Luck <tony.luck@...el.com>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, linux-hardening@...r.kernel.org, 
	Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 1/2] tracing: ring-buffer: Have the ring buffer code do
 the vmap of physical memory

On Mon, 31 Mar 2025 at 17:11, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I thought you did that already for the user mappings - don't use you
> remap_pfn_range()?
>
> That's basically the equivalent of vmap_page_range() - you're mapping
> a whole range based on physical addresses, not mapping individual
> pages.

Btw, if you are wondering why this isn't consistent: for user space
mapping 'remap_pfn_range()' takes a starting physical 'pfn' and a
size, while for kernel space 'vmap_page_range()' takes a 'phys_addr_t'
and a size, then I have no answers for you.

Except just "random historical accidents".

There are a lot more "map into user space" cases, and it's the much
more common case, and it's the one that a lot of drivers have used for
a long time.

The 'vmap' code in contrast really started out as just "vmalloc()"
which allocated the pages while mapping and "ioremap()" which mapped
in IO areas into kernel virtual memory.

And then the interface has very occasionally gotten updated over the
years and we *have* had some unification, but it's been driven not by
"let's make this a kernel version of user mappings", but by "random
odd use cases".

You can see this just in the statistics: remap_pfn_range() has hundreds of uses.

In contrast, vmap_page_range() has something like five uses - when you
grep for it, half of the hits for it are in the mm/vmalloc.c
implementation and the header file declaration).

So I do think vmap_page_range() is the right thing to do here, but it
is *so* rare that maybe it has issues. There simply generally isn't
any reason to map contiguous pages into kernel space.

The *typical* use for kernel virtual mappings is either

 (a) turn physically discontiguous allocations into a contiguous
virtual mapping (ie "vmalloc" like things, sometimes with
pre-allocated arrays of pages)

or

 (b) map device pages into kernel space (ie "ioremap()" kinds of things)

so vmap_page_range() is kind of an odd and unusual duck, which is why
people may not be all that aware of it.

And being an odd and unusual duck might mean it has bugs, but the good
news is that "vmap_page_range()" is actually the underlying
implementation of "ioremap()", so it *does* actually get tested that
way.

           Linus