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?
