[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kernel aslr: someone interested?
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.
Main Index |
Thread Index |