Le 21/02/2024 à 06:43, Christoph Hellwig a écrit : > 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. 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 ? > >> >> 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.
