Re: [RFC][PATCH 00/24] x86 Kernel Shadow Stacks

[Peter Zijlstra]

On Wed, Oct 21, 2026 at 12:51:20PM -0700, Dave Hansen wrote:

> There are a few critical parts of the design:
>  1. A shadow stack is allocated per-thread. Space is carved out
>     in the thread_info structure, adjacent to the normal stack.
>     vmap'd stacks are leveraged. They already provide an alias of the
>     program stack with 4k pages so it is straightforward to create an
>     alias of the 4k shadow stack page with its special permissions in
>     the same area.
>  2. FRED is a required prerequisite. If someone wants to go back and
>     do an IDT implementation, I'm all for it. But FRED is way simpler
>     and it is absolutely the place to _start_.

SSS has always had FRED as a hard requirement. We're not going to
contemplate doing IDT; its an absolute trainwreck.

>  3. In addition to the per-thread stacks, there are also kernel
>     exception stacks. This is also true for shadow stacks. Leverage
>     the "CEA" infrastructure to allocate space for the exception
>     shadow stacks. (look for "x86/cea" patches).
>  4. The kernel shadow stack pointer needs per-thread storage and needs
>     to be context-switched.
>  5. Any event handling (exceptions or interrupts) that modifies the
>     "return to" instruction pointer now needs corresponding changes
>     to the shadow stack event frame.
> 
> == Warts ==
> 
> In order of things I want folks looking at.
> 
>  * The shadow stack is not used for the init_task. The most ideal
>    thing would be to find a convenient, simple time where the regular
>    stack is shallow and it is simple to create a corresponding shadow
>    stack. This is not currently done.

This; I'm thinking we should simply unwind our own stack and write the
return frames in the shadow-stack and switch. We have all the
infrastructure for this to be 'trivial'.

Trying to support non-ss tasks looks like a complete nightmare, lets not
do that.