I should have guessed that. Apologies.
2
6
Many things are discovered multiple times It happens so often that me or my colleagues have a brilliant idea and just in the search for related work discover that someone already had this idea, often under a different terminology. And I consider it a good sign to have ideas that
2
1
7
and what do you do with those discovered related works? bury them and never ever mention them in your own work or give proper credit? as a sidenote, the CCS05 CFI paper references my other work (ASLR), *except* the one that made their work not novel.
2
2
9
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..

Dec 13, 2018 · 8:02 AM UTC

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
nope, read nitter.vloup.ch/paxteam/status/1… again and understand what exemplify means. for background, all these docs were written during a short contracting gig in 2002 for subject matter experts at the client who were already familiar with my work, academic publication wasn't the focus.
(i think pax.grsecurity.net/docs/ is a better reference). there're 3 strategies outlined for control flow protection in there (read-only/type check/'encryption'), each exemplified with one kind of code ptr but that doesn't mean they don't apply to the other kind.
1
With all due respect to @paxteam’s groundbreaking work, I have to agree with @gannimo in this. An idea/vision doesn’t match against a foundational study, where Abadi & Blanchet is miles ahead of pax-future.txt. Also, nothing about “types” in pax-future.txt
3
4
miles ahead? maybe for academics who had been always behind the state of the art by a couple of years, but there was nothing new in there for me and other subject matter experts (you yourself should know better given how many times we discussed these topics at the sous bock ;).
1
1