Thread (17 messages) 17 messages, 5 authors, 2024-02-21

Re: [PATCH 1/4] mm/vmalloc: allow arch-specific vmalloc_node overrides

From: Christophe Leroy <hidden>
Date: 2024-02-21 07:38:36
Also in: bpf, linux-arch, linux-efi, linux-mm, linux-riscv, linux-s390, lkml


Le 21/02/2024 à 06:43, Christoph Hellwig a écrit :
On Tue, Feb 20, 2024 at 02:32:53PM -0600, Maxwell Bland wrote:
quoted
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.
We have MODULES_VADDR and MODULES_END that are used by arm, arm64, 
loongarcg, powerpc, riscv, s390, sparc, x86_64

is_vmalloc_or_module_addr() is using MODULES_VADDR so I guess this 
function fails on mips ?
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help