Supervisor mode access prevention

Posted Sep 27, 2012 1:05 UTC (Thu) by spender (guest, #23067)
Parent article: Supervisor mode access prevention

Users of grsecurity and PaX have had this same protection (and more) for the past 6 years. See: http://forums.grsecurity.net/viewtopic.php?f=7&t=3046

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.

-Brad

Supervisor mode access prevention

Posted Oct 4, 2012 6:02 UTC (Thu) by kevinm (guest, #69913) [Link] (1 responses)

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 (guest, #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.