Re: [PATCH] x86/shstk: shadow stack enabling write return code change
From: Edgecombe, Rick P
Date: Tue Jul 07 2026 - 14:19:57 EST
On Mon, 2026-06-15 at 15:00 -0500, Bill Roberts wrote:
> When enabling write to a shadow stack that is not enabled
>
This^ part is hard to read. How about:
The WRSS instruction (the special instruction that writes to shadow stacks)
cannot be used in userspace unless IA32_U_CET.SH_STK_EN=1 (user shadow stack is
enabled). So the kernel returns -EINVAL to userspace if it tries to enable it
when shadow stack is disabled. However...
> , it will
> return EPERM. However, that error code doesn't fit the condition and it
> should be EINVAL, as that state change cannot be fulfilled due to an
> invalid argument not a permissions issue.
>
> Investigating userspace call sites,
>
I'm guessing this is glibc and the selftests? Can you be specific? The tense
change is a bit weird too. Maybe something like:
Userspace calls sites in foo, bar, ... do not rely on...
> they do not rely on this specific
> error message, nor could userspace effectively utilize this specific
> return error code to indicate a difference in "I cannot enable
> write because of invalid permissions" versus "I cannot enable write
> because the shadow stack is disabled".
>
> Signed-off-by: Bill Roberts <bill.roberts@xxxxxxx>
> ---
> arch/x86/kernel/shstk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
> index 0ca64900192f..eb690ba90180 100644
> --- a/arch/x86/kernel/shstk.c
> +++ b/arch/x86/kernel/shstk.c
> @@ -490,7 +490,7 @@ static int wrss_control(bool enable)
> * when disabling.
> */
> if (!features_enabled(ARCH_SHSTK_SHSTK))
> - return -EPERM;
> + return -EINVAL;
>
> /* Already enabled/disabled? */
> if (features_enabled(ARCH_SHSTK_WRSS) == enable)