Let me reiterate: in the pax-future paper you propose protecting returns. For the forward edge you only propose to write-protect as many function pointers as possible. While reducing attack surface, that's not CFI 🙃 (Also, idea != design, implementation, evaluation, discussion)

Did RAP reference KCoFI? Happens both ways. Terrible thing is that RAP then caused other academics to assume it was the only kernel control flow integrity system.

overhead of 2x-3.5x is not a legitimate solution, it's an irrelevant academic toy, also wasn't fine-grained (see sources for both below). Anyone who works on this stuff knows there is a huge difference between a toy and a feature-complete, high-performance, fine-grained CFI

One example: RAP has over 1MB of type correctness fixes necessary to achieve fine-grained CFI -- you neither need to implement the entire static analysis framework to find those, nor fix them, in basic coarse-grained CFI

So if we start lowering the bar on these kinds of claims to academic toy quality, private versions of RAP from the fall of 2013 (before the H2HC presentation in 2015) were booting Linux and would have qualified

Totally missed this tweet. It's clear that both the policy of KCoFI and its engineering could be improved a ton. But notice, KCoFI protects the MMU. RAP does not. MMU isolation is not cheap. Yes academic, but demonstrates a powerful point. ret2dir is a good attack to consider.

I understand the point (obviously it's nothing new for us), but pointing out RAP not doing it is equivalent to complaining RAP itself doesn't provide W^X for userland. When you don't try shoehorning something into a particular approach (say by masking all memory writes)...

then it has a has a chance of actually being used and not some toy exercise with terrible performance. There are a lot of ton of ways you can "solve" problems with methods that have terrible perf -- it's not interesting or noteworthy, but a primary reason for academic paper churn

ret2dir is unrelated and irrelevant under RAP + KERNEXEC really, happy to explain why in a million ways if you disagree ;)

Not buying your arg on performance. You quote micro benchmarks, but in macro we see < 3% overhead (on FreeBSD) when compiling the kernel for MMU isolation alone. This without batching updates to the MMU, zero optimizations. We do however mess with superpages, a good arg from pax.