Le 20/02/2024 à 21:32, Maxwell Bland a écrit : > [Vous ne recevez pas souvent de courriers de mbland@xxxxxxxxxxxx. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > 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. > > 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. > > Two benefits of this approach are (1) greater flexibility to each > architecture for handling of virtual memory while not compromising the > kernel's vmalloc logic and (2) more uniform use of the __vmalloc_node > interface, reserving the more specialized __vmalloc_node_range for more > specialized cases, such as kasan's shadow memory. I'm not sure I understand the message. What I understand is that you allow architectures to override vmalloc_node(). In the code you add __weak for that. But you also add the flags to the parameters and I can't understand why when reading the above description. Christophe
