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.

Sorry for the confusion. Didn’t imply comparing. Different properties different goals. Merely confused about the claim that 3% overhead is too much for security when RAP hits 5+ (which I think 5% is awesome BTW and assume y’all do as well). Thanks for the education.

Sorry just frustrated to hear an arbitrary # that is violated by the the one setting it.I get comparing sec vs perf.Both MMU integrity and ROP defense are essential. I also get our 3% isn’t on a (claimed but debatably) better benchmark.Reconciling perf reqs?Can’t, it’s arbitrary.