Shadow Stack Locking Semantics between arch's

Shadow Stack Locking Semantics between arch's

[Bill Roberts]

Howdy folks,

If you haven't seen, I have been floating some patches to bring x86-64 
shadow stack controls over to prctl, and it's generally straight forward.
The larger motivation, is that I am doing all of this so we can place 
LSM controls on shadow stack manipulations. For x86 will we need to hook
the old and new implementations.

I have noticed some semantic differences between the arches. Given this 
example of current thread state, current thread locking state and the
new features requested, as shown below:

unsigned long locked = 0x2; // Kernel Task State -> LOCK WRITE
unsigned long cur_val = 0x3; // Kernel Task State -> WRITE and 
SHADOWSTACK ENABLED
unsigned long new_val = 0x0; // Userspace Feature Change via syscall -> 
DISABLE

| x86-64 | risc-v | arm64 |
| ---------- | -------- | --------- |
| Works  | Fails  | Fails     |

Besides the locking difference, I have also noticed a few other issues 
noted below:

Risc-v:
- shouldn't reject all bits in locking, it supports shadow stack.
- shouldn't return EINVAL on locking checks

See the code snippets for these below:

if (is_shstk_locked(t))
                 return -EINVAL;

int arch_lock_shadow_stack_status(struct task_struct *task,
                                   unsigned long arg)
{
         /* If shtstk not supported or not enabled on task, nothing to 
lock here */
         if (!is_user_shstk_enabled() ||
             !is_shstk_enabled(task) || arg != 0)
                 return -EINVAL;

         set_shstk_lock(task, true);

         return 0;
}

arm64:
1. Locking failures return -EBUSY vs -EPERM, I spoke with Mark (on CC) 
he seemed OK with this,

I would like to find a way to rectify this so userspace has a common API.

I am proposing and have questions over the following:
1. What should the behavior be if you had write locked and disable the 
shadow stack?
   - I can argue both ways here, -EPERM or success. I think I and most 
arches lead to failure.
2. riscv should check that the low bit is set in locking not just that 
its 0, it should be 1
3. riscv should return -EPERM vs -EINVAL
4. x86 locking state should fail

If we can all agree on item 1, that locked bits check can be refactored 
and shared in one of
two ways:
1. within prctl itself, before the arch hook is called, we would need 
helpers per-arch to extract the thread features and lock bits
2. as a helper where folks just pass the unsigned long of the bits to 
get the result

Thanks everyone

Re: Shadow Stack Locking Semantics between arch's

[Bill Roberts]

On 8/27/26 12:15 PM, Bill Roberts wrote:

Sorry resend, wrong outgoing mail server in my client so it got mangled, 
this one should be proper...

Howdy folks,

If you haven't seen, I have been floating some patches to bring x86-64 
shadow stack controls over to prctl, and it's generally straight forward.
The larger motivation, is that I am doing all of this so we can place 
LSM controls on shadow stack manipulations. For x86 will we need to hook
the old and new implementations.

I have noticed some semantic differences between the arches. Given this 
example of current thread state, current thread locking state and the
new features requested, as shown below:

unsigned long locked = 0x2; // Kernel Task State -> LOCK WRITE
unsigned long cur_val = 0x3; // Kernel Task State -> WRITE and 
SHADOWSTACK ENABLED
unsigned long new_val = 0x0; // Userspace Feature Change via syscall -> 
DISABLE

| x86-64 | risc-v | arm64 |
| ---------- | -------- | --------- |
| Works  | Fails  | Fails     |

Besides the locking difference, I have also noticed a few other issues 
noted below:

Risc-v:
- shouldn't reject all bits in locking, it supports shadow stack.
- shouldn't return EINVAL on locking checks

See the code snippets for these below:

if (is_shstk_locked(t))
                 return -EINVAL;

int arch_lock_shadow_stack_status(struct task_struct *task,
                                   unsigned long arg)
{
         /* If shtstk not supported or not enabled on task, nothing to 
lock here */
         if (!is_user_shstk_enabled() ||
             !is_shstk_enabled(task) || arg != 0)
                 return -EINVAL;

         set_shstk_lock(task, true);

         return 0;
}

arm64:
1. Locking failures return -EBUSY vs -EPERM, I spoke with Mark (on CC) 
he seemed OK with this,

I would like to find a way to rectify this so userspace has a common API.

I am proposing and have questions over the following:
1. What should the behavior be if you had write locked and disable the 
shadow stack?
   - I can argue both ways here, -EPERM or success. I think I and most 
arches lead to failure.
2. riscv should check that the low bit is set in locking not just that 
its 0, it should be 1
3. riscv should return -EPERM vs -EINVAL
4. x86 locking state should fail

If we can all agree on item 1, that locked bits check can be refactored 
and shared in one of
two ways:
1. within prctl itself, before the arch hook is called, we would need 
helpers per-arch to extract the thread features and lock bits
2. as a helper where folks just pass the unsigned long of the bits to 
get the result

Thanks everyone

Re: Shadow Stack Locking Semantics between arch's

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2950 bytes --]

On Thu, Aug 27, 2026 at 12:52:28PM -0500, Bill Roberts wrote:

> I have noticed some semantic differences between the arches. Given this
> example of current thread state, current thread locking state and the
> new features requested, as shown below:

> unsigned long locked = 0x2; // Kernel Task State -> LOCK WRITE
> unsigned long cur_val = 0x3; // Kernel Task State -> WRITE and SHADOWSTACK
> ENABLED
> unsigned long new_val = 0x0; // Userspace Feature Change via syscall ->
> DISABLE

> | x86-64 | risc-v | arm64 |
> | ---------- | -------- | --------- |
> | Works  | Fails  | Fails     |

I would not have expected that combination to work at all with the
prctl() (as opposed to arch_prctl()) interface TBH, if you've locked
write on you shouldn't be able to disable it.  The reason that works on
x86 at the minute is that for x86 you can only change one bit at a time
so the new value when disabling is effectively 0x2, not 0x0.

> I am proposing and have questions over the following:
> 1. What should the behavior be if you had write locked and disable the
> shadow stack?
>   - I can argue both ways here, -EPERM or success. I think I and most arches
> lead to failure.

Given that RISC-V doesn't support control of writes it's moot there
at the minute, and x86 currently uses arch_prctl() so will need an
additional API, it seems the path of least resistance is to allow it.
This also avoids locking writes (or pushes, for arm64) on effectively
also locking enable which seems neater.

> 2. riscv should check that the low bit is set in locking not just that its
> 0, it should be 1

I think for ABI compatibility RISC-V will have to continue accepting 0
as being equivalent to locking PR_SHADOW_STACK_ENABLE (or everything,
but it only supports that one bit right now).

> 3. riscv should return -EPERM vs -EINVAL

If you mean for arch_lock_shadow_stack_status() I think -EINVAL is a
sensible error code when the system or task does not support shadow
stacks, I'm not sure we should return -EPERM at all.  On arm64 we
support locking any bit, not just the ones that we currently know about.
This is for future proofing, userspace can lock unknown flags.

> If we can all agree on item 1, that locked bits check can be refactored and
> shared in one of
> two ways:
> 1. within prctl itself, before the arch hook is called, we would need
> helpers per-arch to extract the thread features and lock bits
> 2. as a helper where folks just pass the unsigned long of the bits to get
> the result

For me option 1 seems a bit nicer, and moves more of the implementation
into generic code which is something we should really be doing in
general with the shadow stack support - there's a lot of cross arch
duplication at the minute.  It has been on my list to look at this
repitition at some point, it had been held up by the clone3() stuff but
that seems to have died a death for now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Shadow Stack Locking Semantics between arch's

[Edgecombe, Rick P]

On Thu, 2026-08-27 at 19:14 +0100, Mark Brown wrote:
> On Thu, Aug 27, 2026 at 12:52:28PM -0500, Bill Roberts wrote:
> 
> > I have noticed some semantic differences between the arches. Given this
> > example of current thread state, current thread locking state and the
> > new features requested, as shown below:
> 
> > unsigned long locked = 0x2; // Kernel Task State -> LOCK WRITE
> > unsigned long cur_val = 0x3; // Kernel Task State -> WRITE and SHADOWSTACK
> > ENABLED
> > unsigned long new_val = 0x0; // Userspace Feature Change via syscall ->
> > DISABLE
> 
> > > x86-64 | risc-v | arm64 |
> > > ---------- | -------- | --------- |
> > > Works  | Fails  | Fails     |
> 
> I would not have expected that combination to work at all with the
> prctl() (as opposed to arch_prctl()) interface TBH, if you've locked
> write on you shouldn't be able to disable it.  The reason that works on
> x86 at the minute is that for x86 you can only change one bit at a time
> so the new value when disabling is effectively 0x2, not 0x0.

makes sense.

> 
> > I am proposing and have questions over the following:
> > 1. What should the behavior be if you had write locked and disable the
> > shadow stack?
> >   - I can argue both ways here, -EPERM or success. I think I and most arches
> > lead to failure.
> 
> Given that RISC-V doesn't support control of writes it's moot there
> at the minute, and x86 currently uses arch_prctl() so will need an
> additional API, it seems the path of least resistance is to allow it.
> This also avoids locking writes (or pushes, for arm64) on effectively
> also locking enable which seems neater.

Hmm. I can't think of a reason to lock writes and not lock shadow stack too.
Given likely no one is doing this, I wonder if we could change x86's behavior to
match the others?

The API would makes more sense to prevent disabling shadow stack if writes were
enabled. It could return an EINVAL regardless if it is locked or not? Is that
the arm behavior (forgetting about locked)?


> 
> > 2. riscv should check that the low bit is set in locking not just that its
> > 0, it should be 1
> 
> I think for ABI compatibility RISC-V will have to continue accepting 0
> as being equivalent to locking PR_SHADOW_STACK_ENABLE (or everything,
> but it only supports that one bit right now).
> 
> > 3. riscv should return -EPERM vs -EINVAL
> 
> If you mean for arch_lock_shadow_stack_status() I think -EINVAL is a
> sensible error code when the system or task does not support shadow
> stacks, I'm not sure we should return -EPERM at all.  On arm64 we
> support locking any bit, not just the ones that we currently know about.
> This is for future proofing, userspace can lock unknown flags.
> 
> > If we can all agree on item 1, that locked bits check can be refactored and
> > shared in one of
> > two ways:
> > 1. within prctl itself, before the arch hook is called, we would need
> > helpers per-arch to extract the thread features and lock bits
> > 2. as a helper where folks just pass the unsigned long of the bits to get
> > the result
> 
> For me option 1 seems a bit nicer, and moves more of the implementation
> into generic code which is something we should really be doing in
> general with the shadow stack support - there's a lot of cross arch
> duplication at the minute.  
> 

+1

> It has been on my list to look at this
> repitition at some point, it had been held up by the clone3() stuff but
> that seems to have died a death for now.

Oh? What was the blocker?

Re: Shadow Stack Locking Semantics between arch's

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On Thu, Aug 27, 2026 at 09:27:06PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-08-27 at 19:14 +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2026 at 12:52:28PM -0500, Bill Roberts wrote:

> > > I am proposing and have questions over the following:
> > > 1. What should the behavior be if you had write locked and disable the
> > > shadow stack?
> > >   - I can argue both ways here, -EPERM or success. I think I and most arches
> > > lead to failure.

> > Given that RISC-V doesn't support control of writes it's moot there
> > at the minute, and x86 currently uses arch_prctl() so will need an
> > additional API, it seems the path of least resistance is to allow it.
> > This also avoids locking writes (or pushes, for arm64) on effectively
> > also locking enable which seems neater.

> Hmm. I can't think of a reason to lock writes and not lock shadow stack too.
> Given likely no one is doing this, I wonder if we could change x86's behavior to
> match the others?

> The API would makes more sense to prevent disabling shadow stack if writes were
> enabled. It could return an EINVAL regardless if it is locked or not? Is that
> the arm behavior (forgetting about locked)?

arm64 currently treats each bit independently for simplicity.  The main
use case I see for actually doing that is for preventing enabling writes
or pushes, though in practice I'd expect something doing locks to just
fully lock everything after having enabled the shadow stack.  We can compose
the features easily enough so it seemed most straightforward to just let
userspace decide what it wants, it keeps the implementation simpler.

> > It has been on my list to look at this
> > repitition at some point, it had been held up by the clone3() stuff but
> > that seems to have died a death for now.

> Oh? What was the blocker?

Basically the glibc people weren't convinced they'd ever want to reuse a
shadow stack at which point having the kernel free and reallocate each time
is just as easy.  It saves having to handle corner cases with threads that
didn't exit cleanly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Shadow Stack Locking Semantics between arch's

[Edgecombe, Rick P]

On Thu, 2026-08-27 at 22:41 +0100, Mark Brown wrote:
> On Thu, Aug 27, 2026 at 09:27:06PM +0000, Edgecombe, Rick P wrote:
> > On Thu, 2026-08-27 at 19:14 +0100, Mark Brown wrote:
> > > On Thu, Aug 27, 2026 at 12:52:28PM -0500, Bill Roberts wrote:
> 
> > > > I am proposing and have questions over the following:
> > > > 1. What should the behavior be if you had write locked and disable the
> > > > shadow stack?
> > > >   - I can argue both ways here, -EPERM or success. I think I and most arches
> > > > lead to failure.
> 
> > > Given that RISC-V doesn't support control of writes it's moot there
> > > at the minute, and x86 currently uses arch_prctl() so will need an
> > > additional API, it seems the path of least resistance is to allow it.
> > > This also avoids locking writes (or pushes, for arm64) on effectively
> > > also locking enable which seems neater.
> 
> > Hmm. I can't think of a reason to lock writes and not lock shadow stack too.
> > Given likely no one is doing this, I wonder if we could change x86's behavior to
> > match the others?
> 
> > The API would makes more sense to prevent disabling shadow stack if writes were
> > enabled. It could return an EINVAL regardless if it is locked or not? Is that
> > the arm behavior (forgetting about locked)?
> 
> arm64 currently treats each bit independently for simplicity.  The main
> use case I see for actually doing that is for preventing enabling writes
> or pushes, though in practice I'd expect something doing locks to just
> fully lock everything after having enabled the shadow stack.
> 

Locking writes as off makes sense to me. But locking writes on, while leaving
shadow stack unlocked. I'm not sure why you would do that. I thought that was
Bill's scenario.


>   We can compose
> the features easily enough so it seemed most straightforward to just let
> userspace decide what it wants, it keeps the implementation simpler.
> 
> > > It has been on my list to look at this
> > > repitition at some point, it had been held up by the clone3() stuff but
> > > that seems to have died a death for now.
> 
> > Oh? What was the blocker?
> 
> Basically the glibc people weren't convinced they'd ever want to reuse a
> shadow stack at which point having the kernel free and reallocate each time
> is just as easy.  It saves having to handle corner cases with threads that
> didn't exit cleanly.

I thought it was also because they wanted finer grained control of stack sizes
too? But yea, if no libc wants it, it's a hard sell.

Re: Shadow Stack Locking Semantics between arch's

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

On Thu, Aug 27, 2026 at 10:37:45PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-08-27 at 22:41 +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2026 at 09:27:06PM +0000, Edgecombe, Rick P wrote:

> > > Hmm. I can't think of a reason to lock writes and not lock shadow stack too.
> > > Given likely no one is doing this, I wonder if we could change x86's behavior to
> > > match the others?

> > > The API would makes more sense to prevent disabling shadow stack if writes were
> > > enabled. It could return an EINVAL regardless if it is locked or not? Is that
> > > the arm behavior (forgetting about locked)?

> > arm64 currently treats each bit independently for simplicity.  The main
> > use case I see for actually doing that is for preventing enabling writes
> > or pushes, though in practice I'd expect something doing locks to just
> > fully lock everything after having enabled the shadow stack.

> Locking writes as off makes sense to me. But locking writes on, while leaving
> shadow stack unlocked. I'm not sure why you would do that. I thought that was
> Bill's scenario.

Yeah, it is.  I can't think why someone would ask for that either, but
equally it's more work to explicitly have a list of combinations we
reject for policy reasons.  At least on arm64 each permission just comes
down to a separate bit in a control register so they're fully
independent all the way down to the hardware.

> > > > It has been on my list to look at this
> > > > repitition at some point, it had been held up by the clone3() stuff but
> > > > that seems to have died a death for now.

> > > Oh? What was the blocker?

> > Basically the glibc people weren't convinced they'd ever want to reuse a
> > shadow stack at which point having the kernel free and reallocate each time
> > is just as easy.  It saves having to handle corner cases with threads that
> > didn't exit cleanly.

> I thought it was also because they wanted finer grained control of stack sizes
> too? But yea, if no libc wants it, it's a hard sell.

They'd rather have just a size control for that, probably a process wide
control would be most useful since it's likely to be the same number for
all threads.  I suspect the main use casse would be someone trying to do
green threads, where there's an extra real thread being created.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Shadow Stack Locking Semantics between arch's

[Edgecombe, Rick P]

On Fri, 2026-08-28 at 14:27 +0100, Mark Brown wrote:
> Yeah, it is.  I can't think why someone would ask for that either, but
> equally it's more work to explicitly have a list of combinations we
> reject for policy reasons.  At least on arm64 each permission just comes
> down to a separate bit in a control register so they're fully
> independent all the way down to the hardware.

If we want to have a unified API (Bill convinced me that we did, but maybe we
should have more discussion on this point), we will need to hammer out the small
differences between the arch's. For technically supported, but nonsensical
combos. I'd think to resolve the differences by not supporting them. But I mean,
it's not the end of the world. In the end we are just talking about confusing a
handful of libc developers. They can be probably handle things.

> 
> > > > > It has been on my list to look at this
> > > > > repitition at some point, it had been held up by the clone3() stuff
> > > > > but
> > > > > that seems to have died a death for now.
> 
> > > > Oh? What was the blocker?
> 
> > > Basically the glibc people weren't convinced they'd ever want to reuse a
> > > shadow stack at which point having the kernel free and reallocate each
> > > time
> > > is just as easy.  It saves having to handle corner cases with threads that
> > > didn't exit cleanly.
> 
> > I thought it was also because they wanted finer grained control of stack
> > sizes
> > too? But yea, if no libc wants it, it's a hard sell.
> 
> They'd rather have just a size control for that, probably a process wide
> control would be most useful since it's likely to be the same number for
> all threads.  I suspect the main use casse would be someone trying to do
> green threads, where there's an extra real thread being created.

Ok, don't want to re-litigate anything. But at some point someone was talking
about a case where you needed to create a special large stack.

In general it makes sense to not add this if no one is pestering about it.

Re: Shadow Stack Locking Semantics between arch's

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Fri, Aug 28, 2026 at 04:48:36PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2026-08-28 at 14:27 +0100, Mark Brown wrote:

> > Yeah, it is.  I can't think why someone would ask for that either, but
> > equally it's more work to explicitly have a list of combinations we
> > reject for policy reasons.  At least on arm64 each permission just comes
> > down to a separate bit in a control register so they're fully
> > independent all the way down to the hardware.

> If we want to have a unified API (Bill convinced me that we did, but maybe we
> should have more discussion on this point), we will need to hammer out the small
> differences between the arch's. For technically supported, but nonsensical
> combos. I'd think to resolve the differences by not supporting them. But I mean,
> it's not the end of the world. In the end we are just talking about confusing a
> handful of libc developers. They can be probably handle things.

I think it's similar to differences due to architecture features - only
arm64 supports _PUSH because it's the only one with that feature, users
will have to work out something to do about that.  If someone has a
burning desire to lock weird feature combinations that can't be provided
everywhere they'll have similar issues but I don't see much benefit in
writing code we don't need to.  We should specify what happens if the
architecture can't do what was asked (return -EINVAL?) but I think it's
reasonable to allow the exact restrictions to vary so long as the
sensible cases all work.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]