Cite it. Kind of stupid or passive aggressive question ;)
1
3
thanks for playing, it was neither :). you just shamed pretty much the entire academic CFI crowed.
1
I disagree on that part. You assume things you cannot know, that is someone being aware of a specific work maliciously avoids citing it for whatever reasons. And additionally, as this went through peer review, that the reviewers were fine with this. [1/2]
2
i don't assume, i know for a fact that say @gannimo knew about RAP when he wrote some of his CFI related papers. now what? ;)
1
You mean our CFI survey from '17 where we cited your work? What are you trying to imply?
1
1
that and CFIXX, HEXTYPE, etc, where's the citation of my work in there? that CSUR paper added a few down-playing words about my early work and zero about RAP itself, never mind an actual evaluation. you could have asked me to help conduct the tests but you never did. why not?
2
1
2
CFIXX targets vtable pointer integrity for C++. HexType is a sanitizer for C++ type safety. Why should we cite your work there? You describe protecting returns through a set check and read-only code function pointers. We cited some CFI work but not everything.
2
1
for the same reason you cited the Abadi paper? pax-future.txt has all the basic ideas that i later implemented in RAP and predated the CFI paper by 2+ years..
3
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)
6
4
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.
3
anyway, your CFI approach is inferior to RAP, not sure why it'd deserve singling it out among the other inferior works.

Dec 21, 2018 · 1:13 AM UTC

1
Does RAP protect access to the MMU? Specifically CR0. If not then I’m sorry you lose. But yeah I love RAP. Way better than the policy enforced by KCoFI, which is obviously terribly imprecise for returns. And yes I totally missed citations on NK paper, sorry.
3
RAP's job isn't to ensure immutability of code/etc, we have other features for that (KERNEXEC/etc) and no, they're far from complete in that regard, a powerful enough data-only attack can trivially overwrite PTEs to create writable aliases. fixing that w/o perf impact is hard ;).
2