Playing around with clang's shadow stack support. It was removed in clang-9 for x86_64, and even before that AFAIK there was no runtime support to actually set up the shadow stack & gs register. But with clang-8 you can try it out by using a constructor:
Conversation
Replying to
arm64 implementation is shipped for the Pixel kernels and it was landed in the upstream Linux kernel. It runs fine in arm64 QEMU/KVM too. MTE also works in QEMU/KVM which is how we intend to develop hardened_malloc support ideally in the next few months as prep for ARMv9 devices.
1
2
It's really easy to use the arm64 SCS support in QEMU/KVM though. I don't think there's currently anything missing to block simply turning it on and having it booting with everything working for recent kernel versions.
1
2
Replying to
Neat! Do you know if there's any more detail on what went wrong with the x86_64 port? The documentation is a bit vague ("was evaluated using Chromium and was found to have critical performance and security deficiencies")
1
1
Replying to
x86 doesn't have a link register so there's a race between the check and the return. It could have been addressed within the kernel by making stack mappings thread local. Much harder to do for userspace especially since the disappointing MPK feature doesn't have enough keys.
2
2
Replying to
Hmm, what's the attack scenario for exploiting that race? Perhaps naively it seems like if you have enough control to jump in and change the ret addr between check & ret, you're past the point where ShadowStack would help anyway?
1
Replying to
It was meant to be part of the threat model and there was real world exploitation of those vulnerabilities such as the stack exhaustion (stack clash) race exploitation. I don't fully understand why they removed it. Without Chromium interested in moving it forward it was removed.
It's meant to be used alongside full deployment of type-based CFI and the fact that the shadow stack is accessible everywhere and only hidden is another flaw holding it back from fully providing what it's intended to provide. Clang CFI doesn't have those kinds of issues.
1
1
Clang backwards edge CFI is vaporware and if MTE ends up working well for ShadowCallStack there's not much reason to pursue that since the only architectures people doing 99.9% of this work care about are arm64 and x86_64, and x86_64 only matters to them for Windows Chromium.
1
Replying to
Cool :) For context we've been trying to apply various mitigations like this, forward-edge CFI, and CPI in the Linux kernel but apply them selectively to parts that are more likely to be vulnerable.
1
1
Replying to
Pixels ship Clang CFI + SCS for the Linux kernel and while upstream is likely missing some changes to use CFI those are all in the Android common kernels for arm64. I'm not sure how CFI is progressing for x86_64. If Android cared about x86, they'd probably have added back SCS.
1