Re: Shadow Stack Locking Semantics between arch's

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

>>>> 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.
>> Yes, this is exactly what I am pointing out. Implementation aside, is that
>> the behavior we want?
> It seems more helpful to support changing more than one bit at once.
+ Rick in "to", I want him to weigh in as well.

I think we're still miscommunicating.  The issue is, that in the current
interface for x86 via arch_prctl, which is one bit at a time, the explicit
locking of write can be undone via turning off the shadow stack. Should
that succeed, or should that fail since it implicitly turns off write? 
Should
we preserve that as we port to prctl? Should we change that in x86
arch_prctl, was that intended?