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

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

[Bill Roberts]

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 *should* return -EINVAL to userspace if
it tries to enable it when shadow stack is disabled. However, currently,
it will return -EPERM. But, that error code doesn't fit the condition as
the failure is due to an invalid state change request not a permission
issue.

Investigating userspace call sites, like glibc and criu (checkpoint code),
they do not rely on this specific error message, nor could a 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)
-- 
2.54.0

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

[Edgecombe, Rick P]

On Tue, 2026-07-07 at 13:45 -0500, Bill Roberts wrote:
> 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 *should* return -EINVAL to userspace if
> it tries to enable it when shadow stack is disabled. However, currently,
> it will return -EPERM. But, that error code doesn't fit the condition as
> the failure is due to an invalid state change request not a permission
> issue.
> 
> Investigating userspace call sites, like glibc and criu (checkpoint code),
> they do not rely on this specific error message, nor could a 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>

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.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)

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

[Dave Hansen]

On 7/7/26 11:45, Bill Roberts wrote:
> 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 *should* return -EINVAL to userspace if
> it tries to enable it when shadow stack is disabled. However, currently,
> it will return -EPERM. But, that error code doesn't fit the condition as
> the failure is due to an invalid state change request not a permission
> issue.
> 
> Investigating userspace call sites, like glibc and criu (checkpoint code),
> they do not rely on this specific error message, nor could a 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".

Hi Bill,

Thanks for the patch. One bit of context I'd appreciate: why do you
care? Were you just auditing the code and something seemed wrong? Were
you doing some ARM code and noticed a mismatch?

What motivated the change?

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

[Bill Roberts]

On 7/8/26 11:46 AM, Dave Hansen wrote:
> On 7/7/26 11:45, Bill Roberts wrote:
>> 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 *should* return -EINVAL to userspace if
>> it tries to enable it when shadow stack is disabled. However, currently,
>> it will return -EPERM. But, that error code doesn't fit the condition as
>> the failure is due to an invalid state change request not a permission
>> issue.
>>
>> Investigating userspace call sites, like glibc and criu (checkpoint code),
>> they do not rely on this specific error message, nor could a 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".
> Hi Bill,
>
> Thanks for the patch. One bit of context I'd appreciate: why do you
> care? Were you just auditing the code and something seemed wrong? Were
> you doing some ARM code and noticed a mismatch?
>
> What motivated the change?

Hi Dave, long time no see. So the motivation for the patches is around
adding LSM controls on disabling or making the shadow stack writable.

So, as part of that work, which will be forthcoming very soon, is
supporting the prctl interface for x86 shadow stack controls, so that
the LSMs  are arch agnostic. This also provides a common userspace
shadow stack API for all archs currently supporting this feature (x86, 
arm64, riscv).
This would also let things, like glibc, have a common UAPI.

It's important to note that this work I describe, leaves the arch_prctl 
interface
intact, and it will need an lsm hook for controls via arch_prctl. This 
way both
paths behave the same way.

Now for this patch. I noticed this issue when I was doing negative testing
from userspace via prctl and the return value didn't match what was in
the pcrtl man page.

Thanks,
Bill

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

[Dave Hansen]

On 7/8/26 13:56, Bill Roberts wrote:
> Now for this patch. I noticed this issue when I was doing negative testing
> from userspace via prctl and the return value didn't match what was in
> the pcrtl man page.

Ahh, that's the bit of background I was looking for. Thanks for that,
and thanks for the patch!

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

[Bill Roberts]

On 7/8/26 4:00 PM, Dave Hansen wrote:
> On 7/8/26 13:56, Bill Roberts wrote:
>> Now for this patch. I noticed this issue when I was doing negative testing
>> from userspace via prctl and the return value didn't match what was in
>> the pcrtl man page.
> Ahh, that's the bit of background I was looking for. Thanks for that,
> and thanks for the patch!
Hey Dave, just to clarify, is there anything else here I need to do for 
an ack, or can I consider this staged?
I also sent out the prctl changes this am, so you can see more of the 
context.

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

[Dave Hansen]

On 7/14/26 13:22, Bill Roberts wrote:
> On 7/8/26 4:00 PM, Dave Hansen wrote:
>> On 7/8/26 13:56, Bill Roberts wrote:
>>> Now for this patch. I noticed this issue when I was doing
>>> negative testing from userspace via prctl and the return value
>>> didn't match what was in the pcrtl man page.
>> Ahh, that's the bit of background I was looking for. Thanks for
>> that, and thanks for the patch!
> Hey Dave, just to clarify, is there anything else here I need to do
> for an ack, or can I consider this staged? I also sent out the prctl
> changes this am, so you can see more of the context.
It's in my list of things to queue. I'll probably push it out in a day
or two.

[tip: x86/cpu] x86/shstk: Shadow stack enabling write return code change

[tip-bot2 for Bill Roberts]

The following commit has been merged into the x86/cpu branch of tip:

Commit-ID:     f4cadf2d1ee3a24f259495309b76f98af467004b
Gitweb:        https://git.kernel.org/tip/f4cadf2d1ee3a24f259495309b76f98af467004b
Author:        Bill Roberts <bill.roberts@arm.com>
AuthorDate:    Tue, 07 Jul 2026 13:45:42 -05:00
Committer:     Dave Hansen <dave.hansen@linux.intel.com>
CommitterDate: Wed, 02 Sep 2026 14:06:27 -07:00

x86/shstk: Shadow stack enabling write return code change

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 *should* return -EINVAL to userspace if
it tries to enable it when shadow stack is disabled. However, currently,
it will return -EPERM. But, that error code doesn't fit the condition as
the failure is due to an invalid state change request not a permission
issue.

Investigating userspace call sites, like glibc and criu (checkpoint code),
they do not rely on this specific error message, nor could a 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>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Link: https://patch.msgid.link/20260707184542.1721085-1-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 0ca6490..eb690ba 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)