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.

as for <3% overhead: it's WAY too much when in practice the TOTAL budget you have for ALL security related changes is single digit impact for the WORST case. consequently, the perf impact of any security enhancement must be proportional to its overall security value.

"As a demonstration of its high security benefit to performance cost ratio, we're also providing the following benchmarks below, where RAP demonstrates a 5.4% performance hit in a "worst-case" kernel-bounded workload." No one uses RAP then? I respect you but don't waste my time.