Re: [PATCH] x86/shstk: shadow stack enabling write return code change

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

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@arm.com>
> ---
>  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)