Providing user control over page faults and using that for a security exploit reminds me of the classic UNIX tale of password checking. A version of UNIX had a privileged mechanism that would check a password (provided by pointer); it did so character-by-character. It also had a way for userspace processes to handle page faults themselves. So, put a password buffer across two pages, with the page boundary after the first character, and change the first character until you get a page fault. Repeat for each character of the password...
So yet another KASLR bypass.<p>Reminds me of[1]:<p>> Consider this our "I told you so" that we hope you'll remember in the coming years as KASLR is "broken" time and again. Then again, in this offensive-driven industry, that's where the money is, isn't it?<p>[1] <a href="https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=ee9f8c1bacede4863bcab77b96eff623" rel="nofollow">https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=e...</a>
To me it seems like every time intel tries to create a security safeguard, it almost always without exception ends up being a new attack-vector instead (see "x86 considered harmful").<p>I'd love to run simpler versions of the modern intel cpus stripped of all this insecure bloat.<p>Surely I can't be the only one?
(This popped up on proggit the other day, but got deleted for some reason: <a href="https://www.reddit.com/r/programming/comments/58fpi6/aslr_protection_on_intel_haswell_takes_only_60ms/" rel="nofollow">https://www.reddit.com/r/programming/comments/58fpi6/aslr_pr...</a> )
For a system as complex and intricate as a modern processor, it seems impossible to avoid a userspace application from figuring out at least some basic information about the kernel's state. It would be better to focus on avoiding actual privilege escalations.