LWN: Comments on "Controlling shadow-stack allocation in clone3()"

Controlling shadow-stack allocation in clone3()

roc — Sat, 09 Dec 2023 00:58:14 +0000

Done, thanks.

Controlling shadow-stack allocation in clone3()

redgecombe — Fri, 08 Dec 2023 22:02:40 +0000

Yep, map_shadow_stack syscall takes an optional address (like mmap), and the CRIU patches used it.

The earlier proposed clone3 design involved userspace allocating the shadow stack and then passing the address into clone3. So it was setting the shadow stack pointer register (SSP) to an arbitrary point, not telling the kernel to allocate the shadow stack at a specific point.

Do you mean rr needs to control where a newly created thread allocates a shadow stack? If so could you comment the details on the mailing list to that series? Keep in mind the SSP is controllable via ptrace, so a tracer should be able to write to shadow stacks, set the SSP wherever it wants, and map shadow stacks at specific locations (via map_shadow_stack injection). So it seems like something could me made to work, but it would be good to know if there are any hard requirements.

Controlling shadow-stack allocation in clone3()

roc — Fri, 08 Dec 2023 19:57:45 +0000

My understanding is that userspace can access shadow stack memory, at least under some conditions, so as an rr maintainer I suspect we are going to need the ability to control where shadow stacks are allocated, so we can ensure during replay the shadow stacks are allocated at the same address as during recording.

But I would have thought CRIU has the same issues, and yet I know CRIU maintainers have been talking to the CET people and this hasn't come up?