netdev - Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data

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]

Date: Mon, 19 Jun 2023 18:23:34 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	"David S. Miller" <davem@...emloft.net>,
	Dinh Nguyen <dinguyen@...nel.org>,
	Heiko Carstens <hca@...ux.ibm.com>, Helge Deller <deller@....de>,
	Huacai Chen <chenhuacai@...nel.org>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nadav Amit <nadav.amit@...il.com>,
	"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Puranjay Mohan <puranjay12@...il.com>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Russell King <linux@...linux.org.uk>, Song Liu <song@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Will Deacon <will@...nel.org>, bpf@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
	linux-mm@...ck.org, linux-modules@...r.kernel.org,
	linux-parisc@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-s390@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, loongarch@...ts.linux.dev,
	netdev@...r.kernel.org, sparclinux@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()

On Mon, Jun 19, 2023 at 12:32:55AM +0200, Thomas Gleixner wrote:
> Mike!
> 
> Sorry for being late on this ...
> 
> On Fri, Jun 16 2023 at 11:50, Mike Rapoport wrote:
> 
> The fact that my suggestions had a 'mod_' namespace prefix does not make
> any of my points moot.

The prefix does not matter. What matters is what we are trying to abstract.
Your suggestion is based of the memory used by modules. I'm abstracting
address spaces for different types of executable and related memory. They
are similar, yes, but they are not the same.

The TEXT, INIT_TEXT and *_DATA do not match to what we have from arch POV.
They have modules with text, rw data, ro data and ro after init data and
the memory for the generated code. The memory for modules and memory for
other users have different restrictions for their placement, so using a
single TEXT type for them is semantically wrong. BPF and kprobes do not
necessarily must be at the same address range as modules and init text does
not differ from normal text.

> Song did an extremly good job in abstracting things out, but you decided
> to ditch his ground work instead of building on it and keeping the good
> parts. That's beyond sad.

Actually not. The core idea to describe address range suitable for code
allocations with a structure and have arch code initialize this structure
at boot and be done with it is the same. But I don't think vmalloc
parameters belong there, they should be completely encapsulated in the
allocator. Having fallback range named explicitly is IMO clearer than an
array of address spaces.

I accept your point that the structures describing ranges for different
types should be unified and I've got carried away with making the wrappers
to convert that structure to parameters to the core allocation function.

I've chosen to define ranges as fields in the containing structure rather
than enum with types and an array because I strongly feel that the callers
should not care about these parameters. These parameters are defined by
architecture and the callers should not need to know how each and every
arch defines restrictions suitable for modules, bpf or kprobes.

That's also the reason to have different names for API calls, exactly to
avoid having alloc(KPROBES,...), alloc(BPF, ...), alloc(MODULES, ...) an so
on.

All in all, if I filter all the ranting, this boils down to having a
unified structure for all the address ranges and passing this structure
from the wrappers to the core alloc as is rather that translating it to
separate parameters, with which I agree.

> Thanks,
> 
>         tglx

-- 
Sincerely yours,
Mike.