On Fri, Sep 26, 2025 at 05:09:08PM +0100, Mark Brown wrote:
On Fri, Sep 26, 2025 at 03:46:26PM +0000, Edgecombe, Rick P wrote:
On Fri, 2025-09-26 at 01:44 +0100, Mark Brown wrote:
I agree it seems clearly better from a security point of view to have writable shadow stacks than none at all, I don't think there's much argument there other than the concerns about the memory consumption and performance tradeoffs.
IIRC the WRSS equivalent works the same for ARM where you need to use a special instruction, right? So we are not talking about full writable
Yes, it's GCSSTR for arm64.
sspush / ssamoswap on RISC-V provides write mechanisms to shadow stack.
shadow stacks that could get attacked from any overflow, rather, limited spots that have the WRSS (or similar) instruction. In the presence of forward edge CFI, we might be able to worry less about attackers being able to actually reach it? Still not quite as locked down as having it disabled, but maybe not such a huge gap compared to the mmap/munmap() stuff that is the alternative we are weighing.
Agreed, as I said it's a definite win still - just not quite as strong.
If I have to put philosopher's hat, in order to have wider deployment and adoption, its better to have to have better security posture for majority users rather than making ultra secure system which is difficult to use.
This just means that mechanism(s) to write-to-shadow stack flows in user space have to be carefully done.
- Sparse and not part of compile codegen. Mostly should be hand coded and reviewed.
- Reachability of such gadgets and their usage by adversary should be threat modeled.
If forward cfi is enabled, I don't expect gadget of write to shadow stack itself being reachable without disabling fcfi or pivoting/corrupting shadow stack. The only other way to achieve something like that would be to re-use entire function (where sswrite is present) to achieve desired effect. I think we should be focussing more on those.