> Any thoughts on the desirability of this feature wrt randomization of the placement of vmlinux in physical memory? Even with vmlinux randomization in physical memory, dynamically allocated memory ALSO ends up getting predictably placed. If I allocate basically all physical memory, e.g. with mmap, I can predict with >90% accuracy a PFN that was allocated by that mmap with the caveat that my testing was soon after boot so that reliability may go down over time in a real world scenario.
So I think linear map randomization is still relevant in making real-world exploitation more difficult even if vmlinux is randomized in physical memory. On Thu, Jan 8, 2026 at 8:33 AM Ard Biesheuvel <[email protected]> wrote: > > On Tue, 16 Dec 2025 at 19:14, Seth Jenkins <[email protected]> wrote: > > > > > This is posted as an RFC because there are obvious shortcomings to this > > > approach. However, before I spend more time on this, I'd like to gauge > > > if there is any consensus that bringing this back is a good idea. > > I may be a minority, but I do think bringing this back is a good idea. > > It has now been 9+ years since hardware side channels for bypassing > > KASLR were discovered, and it still appears that real-world attackers > > overwhelmingly prefer alternative strategies - such as this one. > > > > I'm under no illusion that if we just do this one thing KASLR will be > > secure again, but I think this patch would still have a meaningful > > real-world impact in terms of making exploits significantly harder to > > write. > > > > Thanks for the feedback. > > I was hoping to get some other views on this matter, but sending the > patch during plumbers and right before the holidays probably didn't > help in that regard, I'm afraid. > > Any thoughts on the desirability of this feature wrt randomization of > the placement of vmlinux in physical memory? AIUI, the main issue > being addressed here is predictable placement of statically allocated > kernel objects in the virtual address space, which could be solved in > either way. Or are there other concerns here? > > Just trying to elicit as much input as possible on the list, so the > maintainers can make an informed decision. > > Thanks, > Ard.
