On Tue, Feb 20, 2024 at 06:41:05PM +0000, Edgecombe, Rick P wrote:
On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote:
- Shadow stack faults on non-shadow stack pages, if flexible shadow
stack handling is in effect, cause the affected page to become a shadow stack page. When this happens, the page filled with invalid address tokens.
Hmm, could the shadow stack underflow onto the real stack then? Not sure how bad that is. INCSSP (incrementing the SSP register on x86) loops are not rare so it seems like something that could happen.
Yes, they'd trash any pages of normal stack they touch as they do so but otherwise seems similar to overflow.
The situation (for arm and riscv too I think?) is that some applications will just not work automatically due to custom stack switching implementations. (user level threading libraries, JITs, etc). So I think it should be ok to ask for apps to change to enable shadow stack and we should avoid doing anything too awkward in pursuit of getting it to work completely transparently.
Yes, on arm64 anything that rewrites or is otherwise clever with the stack is going to have to understand that the GCS exists on arm64 and do matching rewrites/updates for the GCS. This includes anything that switches stacks, it will need to use GCS specific instructions to change the current shadow stack pointer.
MAP_SHARED; I consider this sufficiently perverse application behavior that it is not necessary to ensure exclusive use of the underlying pages while a shadow stack pte exists. (Applications that use MAP_SHARED for stacks do not get the full benefit of the shadow stack but they keep POSIX.1-2004 conformance, applications that allocate stacks exclusively in MAP_PRIVATE memory lose no security.)
On x86 we don't support MAP_SHARED shadow stacks. There is a whole snarl around the dirty bit in the PTE. I'm not sure it's impossible but it was gladly avoided. There is also a benefit in avoiding having them get mapped as writable in a different context.
Similarly for arm64, I think we can physically do it IIRC but between having to map via map_shadow_stack() for security reasons and it just generally not seeming like a clever idea the implementation shouldn't actually let you get a MAP_SHARED GCS it's not something that's been considered.
I am substantially less familiar with GCS and SHSTK than with Zicfiss. It is likely that a syscall or other mechanism is needed to initialize the shadow stack in flexible memory for makecontext.
The ucontext stacks (and alt shadow stacks is the plan) need to have a "restore token". So, yea, you would probably need some syscall to "convert" the normal stack memory into shadow stack with a restore token.
Similar considerations for GCS, we need tokens and we don't want userspace to be able to write by itself in the normal case.