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
Replying to @gannimo
did you read the 'or globally visible' part above?

Dec 27, 2018 · 12:56 PM UTC

2
Replying to @paxteam
Ah, that makes sense. Now if you'd only have a write-up that explains these trade-offs and design choices...
1
Replying to @paxteam @gannimo
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
more replies