Grsecurity Developer Spender's Feelings on the State of Linux Security

Re:Grsecurity Developer Spender's Feelings on the State of L... by nickpsecurity on Friday November 06, 2015 @07:25PM (#10522967)

Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take.

Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.

[ Parent | on HN ]

Re:Grsecurity Developer Spender's Feelings on the State of L... by fulafel on Sunday November 08, 2015 @02:46AM (#10527874)

Or you could just use a memory safe language instead of getting into the C mitigation arms race.

Time and time again mitigation techs have gotten widely deployed, exploits have caught up, it's a perpetual cycle. Yes the exploitation gets a little harder each time around, but you don't get sound memory safety that way.

[ Parent | on HN ]

Re:Grsecurity Developer Spender's Feelings on the State of L... by nickpsecurity on Sunday November 08, 2015 @10:13AM (#10528671)

I agree: my main recommendation for new projects. However, avoiding C or porting Linux/BSD to a safe language fell on deaf ears for decades. So, for them, I recommend techniques that work with C and UNIX architecture. Maybe more progress that way.

[ Parent | on HN ]