IIRC I started an email thread when he yelled at me over twitter the last time where I asked if we could meet in person to discuss (a couple of years ago?) ¯\_(ツ)_/¯ I did a quick search but don't keep very old email, so I may be wrong.
2
After we conjugated through all possible permutations of "apply ML wrongly to a security problem which is, in fact, adversarial", I really do not like how some people seem to like going through "conjugate through all possible permutations of how these can be broken"....
3
4
36
I am older but not senile yet, I remember the history of PaX :) You deserve credit for what you invented back in ~2000. RAP is 2016 however, much more recent. You should write more formal papers to seal this in academic history rather than hacker history (if thats your goal)
3
occured in 2006 but for better or worse, i ended up sucked into an unrelated project and couldn't get back to it till 2009. after some related and necessary groundork i began on RAP in 2012 and had a fully booting linux by 2013. in following years i refined many things, [2/n]
RAP isn't 2016 at all. i figured out defenses for the 3 exploit technique categories in 2000(runtime codegen)/~2002(code reuse)/2005(data-only attacks). what took time is actual implementation since i did all this in my spare time. my first attempt at what would become RAP [1/n]
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.
1
if you mean the H2HC presentation then i didn't reference anything tangential as there was simply no time and that was not the topic anyway. not that you referenced any of my related work either ;).
no you don't. that's not how the linux config system works. use menuconfig/etc just like you would with any other kernel feature, duh.
Please tell me how I can evaluate the RAP plugin on a small user-space case study that will allow me to test the analysis and power of the defense.
2
1
you'll have email me your test cases then because the RAP version in PaX is specifically tailored for the kernel, it does not have support for several code constructs you find in userland.
My point is that @paxteam has no basis or justification to yell at academics for not evaluating RAP if it simply cannot be evaluated reasonably.
4
2
Yeah, but @paxteam complains that academics don't evaluate his software but there's a) no documentation b) no source c) no binary d) no information except a presentation. This is not how you get others to evaluate your software.
2
Hm, there is no config option to build the RAP plugin. This is advanced software archaeology where I reverse engineer a plugin that is hidden in a partial kernel patch without any form of documentation. This software would fail any artifact evaluation.
2
1
i wonder what CONFIG_RAP_PLUGIN does then? seriously, you have a PhD in compsec and can't figure out make menuconfig?
Note that I found github.com/hardenedlinux/RAP… which does not contain any readme, installation notes, or information. I tried for 90min to compile and use the binary but ran into several issues. This is as much as I'll try to reverse engineer a broken implementation 🙃
1
1
next time perhaps try, i don't know, the project's homepage for a change? or just email the author if google fails you?
So, I've set out to evaluate RAP this morning, comparing RAP with LLVM-CFI. I've searched for the RAP download for 30min but did not find an open (or even binary) version of the RAP gcc plugin for user-space.
4
2
GIF
your google skills notwithstanding, how does this effort of yours mesh with nitter.vloup.ch/gannimo/status/1… where you said you had already tried (and failed, for unspecified reasons) to evaluate RAP?
Also, we once tried to compare against RAP in a project but ran into compatibility issues and gave up in the end as it was not worth the effort compared to the (stronger?) LLVM-CFI/shadow stack combination.
1
I sincerely doubt it. I myself get a paywall when trying to get the RAP kernel patches. Where is the public version? Its hard to find. If @paxteam wants RAP to become a mainstream academic reference, they should release a PoC code for public evaluation and write a detailed paper.
2
1
it is where all my other work is: PaX. we even announced it when we added RAP to our linux 4.5 patch.
Yeah, the presentation was mentioned a couple of times but it is incredibly sparse and lacks, e.g., target set discussions and other details. Most CFI academics know RAP but it's hard to evaluate/compare without details/specification
2
2
on slide 31 i discussed target sets exemplified on chromium. both the slides and the presentation had to be rather terse as i didn't have all day to speak (and i still managed to steal everyone's lunch time ;).
Is there a RAP paper/implementation somewhere? I suspect there would be more citations and acknowledgment if RAP was more discoverable to those doing research in the field.
2
7
We did not actively or maliciously exclude RAP. As I mentioned before, RAP is a policy that reiterates and reimplements academic ideas. There's no novelty there. Sure, we could (and maybe should) have evaluated for completeness but it would not have made a big difference IMO
1
3
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? ;)
2
2
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
the real irony is that the very CFI paper you're so attached to was actually one of the first (and for long, only) paper that did acknowledge and cite my pioneering non-exec pages related work.