Re: Shadow Stack Locking Semantics between arch's

[Bill Roberts <bill.roberts@foss.arm.com>]

On 9/9/26 12:57 PM, Bill Roberts wrote:
>>
>>> 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).
>
> TL;DR - No users, lets fix it before risc-v lands the userspace side IIUC
>
> I can't find any libc's that support this for risc-v. It appears the 
> glibc
> patches were not merged and I commented on those patches just now
> that the interface is wrong:
>   - 
> https://inbox.sourceware.org/libc-alpha/8a5e21d0-0628-4910-9ad8-165c829e9680@foss.arm.com/
>
> Additionally, stress-ng does it "generically", and it would be broken 
> on a riscv system:
>   - 
> https://sources.debian.org/src/stress-ng/0.22.00-2/stress-prctl.c?hl=1144#L1144
>
> This is a bug and never followed the convention to begin with. So 
> risc-v is
> non-compliant to the spec and this effectively prevents the a true 
> unification
> of a generic prctl interface. The behavior on riscv doesn't adhere to 
> there own docs:
>
>   - 
> https://cdn.kernel.org/doc/html/latest/arch/riscv/zicfiss.html#prctl-enabling 


Sorry I confused two interfaces here, anyway, 
arch_set_shadow_stack_status is fine,
it's the locking interface arch_lock_shadow_stack_status, code snippet 
below:

/* 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;

So even the glibc patches will be fine. But definitely something we want 
to fix.
I am going to float a patch over to the risc-v folks.