Does LLVM even have any sort of efficient shadow stack mechanism for x86/x64? As far as I can remember it’s decently slow and not as secure as PaxTeam’s return address protections. Maybe PaxTeam’s implementation also suffers from mild speed issues in this area.
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
RAP cookies (their primary use case is the kernel, not userland) are not that trivial to break because they change per syscall and kstacks are isolated from other processes so in practice you need very special bugs to be able to read it *and* make use of it in a payload.
Dec 21, 2018 · 12:36 PM UTC
1