On Fri, 2025-09-26 at 01:44 +0100, Mark Brown wrote:
I don't know about substantial, but I'd love to hear some offensive security persons analysis. There definitely was a school of thought though, that shadow stack should be turned on as widely as possible. If we need WRSS to make that happen in a sane way, you could argue there is sort of a security at scale benefit.
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 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.
But for automatic thread created shadow stacks, there is no need to allow userspace to unmap a shadow stack, so the automatically created stacks could simply be msealed on creation and unmapped from the kernel. For a lot of apps (most?) this would work perfectly fine.
Indeed, we should be able to just do that if we're mseal()ing system mappings I think - most likely anything that has a problem with it probably already has a problem the existing mseal() stuff. Yet another reason we should be factoring more of this code out into the generic code, like I say I'll try to look at that.
Agree. But for the mseal stuff, I think you would want to have map_shadow_stack not available.
That seems like something userspace could enforce with existing security mechanisms? I can imagine a system might want different policies for different programs.
Yes, you could already do it with seccomp or something. Not sure if it will work for the distro-wide enabling schemes or not though.