I love the grsec project, they are thinking about security correctly by focusing on classes of bugs, not reactive security snake oil. The current state of things isn't good for anyone except xdev people.

What is the reason grsecurity never got integrated into Linux mainline?

1. It would be a lot of work and grsec doesn't have that much manpower 2. the linux kernel devs have different priorities

Why don't Google's Android team integrate grsec into Android, and then from there into upstream? They have the manpower.

So the kernel parts? Dunno. CFI (mentioned in the paper) is already being worked on. See https://code.google.com/p/chromium/issues/detail?id=469376 et al

Does CFI work with SafeStack[1], and should SafeStack be preferred to -fstack-protector?

[1] http://clang.llvm.org/docs/SafeStack.html

different kinds of CFI have been under active development since 2002 with recent (2013, 2014) deployments to major web browsers like chrome and IE. IE already ships with a forward CFI implementation in windows 10. chrome will probably ship with it real soon now.

before this presentation, the writing was on the wall for code reuse exploits. after this presentation, well, the writing is still on the wall with one more real world system in place.

AFAIK (IE my engineers working on it tell me :P) that CFI was essentially too slow in practice (IE > 5% overhead) until new implementation techniques were developed in the past couple years (literally. I'm pretty sure the last good paper on this was in 2014).

" IE already ships with a forward CFI implementation in windows 10" I didn't think this was true (i thought it was something related to CFI, but not quite), but i'll take your word for it.

pretty much! this 2013 paper added low overhead (4%?) forward and backward CFI at the binary level, tested on internet explorer and firefox: http://www.cs.berkeley.edu/~dawnsong/papers/Oakland2013-CCFI...

this paper (2014) does forward CFI on chrome for 4% overhead: https://www.eecs.harvard.edu/cs261/papers/tice-2014.pdf

IE on windows 8.1 (including adobe flash) is compiled with forward control flow integrity: https://blog.coresecurity.com/2015/03/25/exploiting-cve-2015... note that the exploitation strategy CORE used leveraged JIT, few systems (with some notable exceptions like librando) acknowledge JIT in their work.

so this technology is out there...

because spender doesn't get along. and lkml isn't exactly the most accommodating of places.

Here's to hoping that some of these issues get turned into usable warnings. For example, the casting issues with function pointers should be warnable.