On Mon, Aug 07, 2023 at 11:00:26PM +0100, Mark Brown wrote:
As discussed extensively in the changelog for the addition of this syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the existing mmap() and madvise() syscalls do not map entirely well onto the security requirements for guarded control stacks since they lead to windows where memory is allocated but not yet protected or stacks which are not properly and safely initialised. Instead a new syscall map_shadow_stack() has been defined which allocates and initialises a shadow stack page.
I guess I need to read the x86 discussion after all ;).
Given that we won't have an mmap(PROT_SHADOW_STACK), are we going to have restrictions on mprotect()? E.g. it would be useful to reject a PROT_EXEC on the shadow stack.