On Tue, Feb 2, 2021 at 2:34 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > "I also suspect that everybody has already accepted that KASLR isn't > really working locally anyway (due to all the hw leak models with > cache and TLB timing), so anybody who can look at kernel messages > already probably could figure most of those things out." Honestly, if you have to pass a kernel command line, and there's a big notice in the kernel messages about this, I no longer care. Because it means that people who _do_ care will know about it. But I don't want it to be a kernel config option - if you do debugging, and you want unhidden pointers, you can add it to the kernel command line and make sure it's *your* choice and not some random kernel config by somebody else (ie distro). And yes, my opinion is that KASRL really only works remotely anyway. I think we might as well accept that as a fact, and that it's unlikely that hardware will be fixed in general, even if on _some_ hardware might make it work better than it works in general. Instead of fighting windmills, accept that KASRL is dead locally for the "wide access" cases (ie not necessarily just "shell access", but "local JIT of uncontrolled code"), but do it because the remote case still matters, and because a lot of local accesses are fairly constrained in that they do *not* give random code execution to the local users (but that "fairly constrained" presumably also generally means that they can't do dmesg). Linus