Interestingly, SMAP now makes kernel infoleak vulns even more valuable. Again in this case, as the blog mentions, we're in the lead with several features specifically targeting information leaks.
Regarding what upstream bugs this functionality discovered (generally pertaining to x86-specific hardware as architectures like SPARC would have picked up the errors in core code), I discussed it in my Linux Security Summit presentation in 2010. See: http://grsecurity.net/spender_summit.pdf ,slide 9.
Funny how the writers of history forget these things.
Posted Sep 27, 2012 8:21 UTC (Thu) by liljencrantz (subscriber, #28458)
[Link]
But at least you're not bitter!
Supervisor mode access prevention
Posted Oct 4, 2012 6:02 UTC (Thu) by kevinm (guest, #69913)
[Link]
But that protection was only for those running 32 bit x86 PaX kernels, right? The vestigial segmentation support in x86-64 isn't sufficient for that method to work.
This new hardware feature will work in x86-64 kernels (as you'd expect).
Supervisor mode access prevention
Posted Oct 4, 2012 8:43 UTC (Thu) by PaXTeam (subscriber, #24616)
[Link]
> But that protection was only for those running 32 bit x86 PaX kernels, right?
> The vestigial segmentation support in x86-64 isn't sufficient for that method to work.
i implemented UDEREF on amd64 as well some years ago, but it's a lot less efficient.
> This new hardware feature will work in x86-64 kernels (as you'd expect).
and unfortunately it'll still provide less security than the by then 7-year-old UDEREF/i386 feature in PaX. so SMAP is a step in the right direction, but Intel could have done better, it'd have cost them nothing to make this feature really powerful for certain kernel self-protection purposes. there's some hope that they'll make it better in the next iteration.