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

[Andrew Cooper]

On 21/10/2026 8:51 pm, Dave Hansen wrote:
> == 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.
>  * The context switching assembly is overly complicated and also
>    subverts the safety in the architecture-intended
>    RSTORSSP/SAVEPREVSSP sequence. This is more nicely fixed once all
>    tasks have a shadow stack, including the init task.
>  * Locating the FRED shadow stack event frame is ugly ("Stash kernel
>    SSP on FRED entry"). It is currently implemented by reading the
>    shadow stack pointer during event entry and stashing it on the
>    normal stack. Xen seems to accomplish the goal by unwinding the
>    stack instead, which has more complicated code, but has adds no
>    complexity or overhead to event entry or the entry data structures.

Xen is already in the process of moving to stashing on entry.

Unwinding the shadow stack was necessary at first, and it has taken a
while to sort out some prerequisites, but I don't recommend it as an
approach.


>  * The direct map alias of the shadow stack is left in place. This
>    means that an attacker can write to the shadow stack without needing
>    to leverage one of the very limited WRSS kernel sites. This is a
>    big weakness in the security model. But, kernel shadow stacks with
>    this weakness are still way better than no kernel shadow stacks.
>
> == Future Work / TODO ==
>
>  * The main thing left is to chew through the list of things in the
>    last patch that are incompatible with kernel shadow stacks. There
>    are some quite essential things in there.
>  * Add a "warn on #CP and continue". Good for debugging. But, bad
>    for security. Ideally, a secure kernel would have no easy to
>    reach gadgets to disable shadow stacks.

This looks attractive at first glance, but it's really not.  There is no
safe way to turn CET-SS off.

WRSS, RSTORSSP and INCSSP will #UD when you turn CET-SS off, and even
logic such as

    if (!ssef)
        return;
    wrss(ip, &ssef->ssef_lip);

in regs_set_return_ip() will die with a #UD as you're attempting to not
die from a #CP.

I suggest just leave CET-SS on and power through the reports.  It will
probably be faster overall, and it will definitely be a better end result.


>  * Zap the direct map shadow stack alias. Might also require some
>    performance optimization work to try and constrain the shadow
>    stack allocations to a more modest set of the physical address
>    space so the direct map damage is lessened.
>  * Work with non-vmap stacks
>  * Work with IDT-based systems (without FRED)

🤣  A courageous plan.

~Andrew