linux-kernel - Re: [PATCH 1/4] mm/vmalloc: allow arch-specific vmalloc

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: <ZdWNalbmABYDuFHE@infradead.org>
Date: Tue, 20 Feb 2024 21:43:06 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Maxwell Bland <mbland@...orola.com>
Cc: linux-arm-kernel@...ts.infradead.org, gregkh@...uxfoundation.org,
	agordeev@...ux.ibm.com, akpm@...ux-foundation.org,
	andreyknvl@...il.com, andrii@...nel.org, aneesh.kumar@...nel.org,
	aou@...s.berkeley.edu, ardb@...nel.org, arnd@...db.de,
	ast@...nel.org, borntraeger@...ux.ibm.com, bpf@...r.kernel.org,
	brauner@...nel.org, catalin.marinas@....com,
	christophe.leroy@...roup.eu, cl@...ux.com, daniel@...earbox.net,
	dave.hansen@...ux.intel.com, david@...hat.com, dennis@...nel.org,
	dvyukov@...gle.com, glider@...gle.com, gor@...ux.ibm.com,
	guoren@...nel.org, haoluo@...gle.com, hca@...ux.ibm.com,
	hch@...radead.org, john.fastabend@...il.com, jolsa@...nel.org,
	kasan-dev@...glegroups.com, kpsingh@...nel.org,
	linux-arch@...r.kernel.org, linux@...linux.org.uk,
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org,
	linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
	lstoakes@...il.com, mark.rutland@....com, martin.lau@...ux.dev,
	meted@...ux.ibm.com, michael.christie@...cle.com, mjguzik@...il.com,
	mpe@...erman.id.au, mst@...hat.com, muchun.song@...ux.dev,
	naveen.n.rao@...ux.ibm.com, npiggin@...il.com, palmer@...belt.com,
	paul.walmsley@...ive.com, quic_nprakash@...cinc.com,
	quic_pkondeti@...cinc.com, rick.p.edgecombe@...el.com,
	ryabinin.a.a@...il.com, ryan.roberts@....com,
	samitolvanen@...gle.com, sdf@...gle.com, song@...nel.org,
	surenb@...gle.com, svens@...ux.ibm.com, tj@...nel.org,
	urezki@...il.com, vincenzo.frascino@....com, will@...nel.org,
	wuqiang.matt@...edance.com, yonghong.song@...ux.dev,
	zlim.lnx@...il.com, awheeler@...orola.com
Subject: Re: [PATCH 1/4] mm/vmalloc: allow arch-specific vmalloc_node
 overrides

On Tue, Feb 20, 2024 at 02:32:53PM -0600, Maxwell Bland wrote:
> Present non-uniform use of __vmalloc_node and __vmalloc_node_range makes
> enforcing appropriate code and data seperation untenable on certain
> microarchitectures, as VMALLOC_START and VMALLOC_END are monolithic
> while the use of the vmalloc interface is non-monolithic: in particular,
> appropriate randomness in ASLR makes it such that code regions must fall
> in some region between VMALLOC_START and VMALLOC_end, but this
> necessitates that code pages are intermingled with data pages, meaning
> code-specific protections, such as arm64's PXNTable, cannot be
> performantly runtime enforced.

That's not actually true.  We have MODULE_START/END to separate them,
which is used by mips only for now.

> 
> The solution to this problem allows architectures to override the
> vmalloc wrapper functions by enforcing that the rest of the kernel does
> not reimplement __vmalloc_node by using __vmalloc_node_range with the
> same parameters as __vmalloc_node or provides a __weak tag to those
> functions using __vmalloc_node_range with parameters repeating those of
> __vmalloc_node.

I'm really not too happy about overriding the functions.  Especially
as the separation is a generally good idea and it would be good to
move everyone (or at least all modern architectures) over to a scheme
like this.