Believing in numbers and fair evaluation, I've compared RAP and LLVM-CFI. RAP is faster, LLVM-CFI is more precise. RAP is incredibly hard to use and its future is uncertain while LLVM-CFI is just a command line argument away. Details at nebelwelt.net/blog/20181226-… Comments welcome 🤗
18
28
79
- RAP doesn't blindly emit the corresponding type hash for a function either, it has to be address-taken or globally visible (this latter part can be solved too w/o LTO). [9/n]
1
Hm, it does emit a hash for my test. Maybe I did not study your source code enough. Then, I don't think you can expectant user who wants to use CFI to completely understand all the involved source code. ¯\_(ツ)_/¯
1
did you read the 'or globally visible' part above?
2
it's not a design choice, it's an implementation detail chosen intentionally to force myself to actually fix bad fptr use in real code vs. let it run unmodified (i guess i'll have to cave in on that one some day). as for writeup, read around nitter.vloup.ch/paxteam/status/1… .
PaX Team @paxteam
21 Dec 2018
Replying to @jvanegue @gannimo @lavados @anders_fogh @halvarflake @dakami @0xcharlie
such as optimizations, C++ support (chromium in 2014), xen, etc. all this was done in secret because of the patenting process which only finished recently, so i'm actually more free now to write publicly. we'll see how much time i can spare for this outside family&work. [n/n]
1
Proposal: spend 1/2 of the time you spend complaining on twitter to provide documentation/writeups. You would get more citations, your work would be referenced more fairly, your solutions would be used more broadly, there would be less complaining on twitter, everybody wins.
1
1
sure thing, once you answer my questions i posed at nitter.vloup.ch/paxteam/status/1… . you have a lot to explain re: how you reference documented works. i won't waste my time until you have an explanation for lack of refs for FPValidator, noexec.txt, and the rest.
PaX Team @paxteam
21 Dec 2018
Replying to @gannimo @MattDenton
nitter.vloup.ch/paxteam/status/1… (FPValidator reference), nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1… (which also contradicts your late statements of RAP not being available btw), nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1…, nitter.vloup.ch/paxteam/status/1… are a good start.
1
nitter.vloup.ch/paxteam/status/1… replied nitter.vloup.ch/paxteam/status/1… see RAP eval in blog nitter.vloup.ch/paxteam/status/1… evaluating user-space programs w/ RAP is hard, see blog post nitter.vloup.ch/paxteam/status/1… source!=documentation nitter.vloup.ch/paxteam/status/1… same nitter.vloup.ch/paxteam/status/1… too little too late
PaX Team @paxteam
21 Dec 2018
Replying to @gannimo @lavados @anders_fogh @halvarflake @dakami @0xcharlie
no novelty there? then tell me which of the evaluated works comes anywhere near its performance&security level? oh wait, you'd actually have had to evaluate it to draw that conclusion. next excuse? ;)
3
the more you try to ditch these questions, the worse you'll come out of it at the end, trust me.
1
No no, you're getting it wrong: please provide writeups of your ideas (and evaluations and implementations) and we'll be happy to cite them 🤗
1
1
Replying to @gannimo
like how you have been citing FPValidator or my non-exec work?

Dec 27, 2018 · 2:25 PM UTC

1
Replying to @paxteam
Why do you get so worked up about a couple of citations? IIRC we cite FPValidator in the survey (on mobile so can't check). There's almost 100 CFI papers, due to page limits most cite and discuss the most memorable ones. We also cited your non-exec work a couple of times
2
1
I know that you feel very important and you did a lot of great work. But academics usually discuss "related" work in their papers, not everything that happened in security since the invention of binary. There's always a selection going on.
2