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
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
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
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
there're no replies to my questions. what did you say about FPValidator or noexec.txt/etc again? or what happened when you managed to evaluate RAP 'in a project' some time ago but found yourself looking for RAP these past few weeks? etc.
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.
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
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… .
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
- you should really read upon how to configure a linux kernel and how make menuconfig/etc work. you never manually edit a .config. hint: menuconfig has a search facility and it'll show you where options are, their dependencies, etc. [13/n]
i'm not aware of anything as mature let alone more mature than RAP. are you? LLVM-CFI can't be it since not even Google managed to figure out how to enable it on all of Chrome (not to mention how many years later it came after RAP to its current state). anything else?
2
1
noone can provide such an animal since Chrome is closed source (works really well trusting its security. not.). any other mature mechanismS? (note your own use of the plural)
1
- your llvm makefile misses -fuse-ld=gold (not everyone defaults to it) and also hardcodes clang-4.0 for no good reason. best would be to have CC?= to allow it to be overrriden from the outside (makes it easier to test with multiple compiler versions). [12/n]
We've moved past "the code is the documentation" for software. There are not enough details to reasonably reproduce RAP and @paxteam claims that the closed source version is so much better anyway ¯\_(ツ)_/¯. LLVM ships CFI since 3.7, so since 2015.
2
4
RAP's not closed source (it's GPL in all versions so far) but closed distribution. if you want to evaluate it then i told you how you can get the information you need.
it's not about the default but the code constructs you test it with. your test cases miss cross-DSO for example.
1
- there's no TOCTOU race (.text is read-only). nor would reading the hash vaue into a register fix anything btw, so feel free to elaborate about what you had in mind.[10/n]
1
1
1
- LLVM-CFI's performance impact is so bad that Google had to disable it on several functions in Chrome whereas RAP could build Chromium since 2014 without any such exceptions. [7/n]
1
5
- your benchmark numbers are meaningless because real software has much more complex code sequences and that's where RAP really shines and LLVM-CFI fails badly. [6/n]
1
2