On Sat, Mar 25, 2017 at 09:20:14AM +0100, Maxime Villard wrote: > > Verily, 5-level page trees with higher entropy will be introduced by Intel > soon, the instructions that leak kernel addresses can be made privileged > (UMIP), cache issues are being fixed; and in short, I wouldn't be surprised > if in five years other features appear that make ASLR even more interesting > and faster than static code.
I would, since "static code" is clearly the base case for any address layout scheme. But once you're within a smidge, who cares? Even now, with register renaming and every other trick in the book and *without* ASLR, PIC is still measurably slower than non-PIC in userland. Not much, but try it and see (on modern CPUs you'll need the performance counters, I suspect -- thanks for fixing those). But nobody seems to notice enough to build non-PIC, so... Obviously on VAC platforms ASLR is unacceptably slow. But there aren't many of those left, and we don't build every platform with the same toolchain options anyway (of course). Everyone else that matters has begun to move towards ASLR as the default (many, perhaps most, are there for userspace code already) and it _does_ matter -- if Max's vault7 example doesn't suffice, have a look at those ShadowBrokers firewall exploits that were released a few months back. Each and every one of those comes in several different flavors tweaked for the kernel layout of different versions of the same code on the same platform -- where there are instructions for use (fun to read) they basically say to stop attacking and get expert help if you run into a target where the -- *static* -- kernel layout is unexpected. ASLR increases the work factor for that stuff considerably (though there are obvious approaches if you can zap the early boot code to wire down the "randomization" so it isn't, etc). Yes, there are workloads where we wouldn't want it, but I submit there are also many important cases where we should have it. Thor