Replying to @gannimo
I’m aware of the documents. You didn’t answer my questions.
1
"but isn’t it your job to evaluate all the important, practical implementations available?" No. If we publish new work we compare against available implementations of the state of the art. RAP is neither the state of the art nor available.
3
"How did you feel happy publishing an incomplete paper?" IMO our paper is not incomplete. We compared against all reasonable openly available implementations
1
"Was it because LLVM was clearly better? How did you know?" From the description of LLVM-CFI and the RAP presentation (for what it's worth). We work in software security, not in software archaeology. 🙃
1
"As far as I can remember it’s decently slow and not as secure as PaxTeam’s return address protections" ShadowStack is precise and stronger than RAP on aarch64, it's somewhat crappy on x86-64. SafeStack is precise and stronger than RAP but suffered a little from bit rot
1
Yes, on aarch64 ShadowCallStack is quite good, the “stronger” is debatable. But... did I read that wrong? Did you seriously just say SafeStack was stronger than... anything? (Seriously, stack canaries are better than safestack in any practical code.) please explain.
2
SafeStack/ShadowStack as a property enforce stack integrity, i.e., return addresses cannot be changed due to address equivalence check. RAP enforces type equivalence (all locations with same type end up in a set), therefore inherently over-approximates. nebelwelt.net/publications/f…
1
SafeStack is pretty much trivially breakable with arbitrary read. RAP cookies are breakable too with arbitrary read, but then it’s backed up with the type equivalence. Also, specialized kernel stuff makes RAP cookies much better, I don’t know if you evaluated kernel stuff.
2
Stack buffer overflow is worse for SafeStack since you only corrupt the unsafe stack, and you’re much more likely to get an arbitrary read from that, unless you add canaries, which make the performance much worse. For RAP cookies the overflow is typically caught before arb. read
2
Oh, we have not agreed on an attacker model yet. For SafeStack, we assume that the attacker already has arbitrary read/write and the goal is to protect control flow. Under SafeStack (or ShadowStack) you cannot illegally hijack CF to alternate locations but with RAP you can
2
Replying to @gannimo @MattDenton
safestack is breakable by design since it doesn't withstand an arbitrary read, IIRC there was a paper that implemented such an attack in practice. the only saving grace would be restricting the 'arbitrary' part but then its performance tanks and becomes worse than RAP and others.

Dec 21, 2018 · 12:39 PM UTC