2025-04-24T11:16:19-07:00, Deepak Gupta <de...@rivosinc.com>:
> On Thu, Apr 24, 2025 at 03:36:54PM +0200, Radim Krčmář wrote:
>>2025-04-23T21:44:09-07:00, Deepak Gupta <de...@rivosinc.com>:
>>> On Thu, Apr 10, 2025 at 11:45:58AM +0200, Radim Krčmář wrote:
>>>>2025-03-14T14:39:31-07:00, Deepak Gupta <de...@rivosinc.com>:
>>>>> diff --git a/arch/riscv/include/asm/usercfi.h
>>>>> b/arch/riscv/include/asm/usercfi.h
>>>>> @@ -14,7 +15,8 @@ struct kernel_clone_args;
>>>>> struct cfi_status {
>>>>> unsigned long ubcfi_en : 1; /* Enable for backward cfi. */
>>>>> - unsigned long rsvd : ((sizeof(unsigned long) * 8) - 1);
>>>>> + unsigned long ubcfi_locked : 1;
>>>>> + unsigned long rsvd : ((sizeof(unsigned long) * 8) - 2);
>>>>
>>>>The rsvd field shouldn't be necessary as the container for the bitfield
>>>>is 'unsigned long' sized.
>>>>
>>>>Why don't we use bools here, though?
>>>>It might produce a better binary and we're not hurting for struct size.
>>>
>>> If you remember one of the previous patch discussion, this goes into
>>> `thread_info` Don't want to bloat it. Even if we end shoving into
>>> task_struct,
>>> don't want to bloat that either. I can just convert it into bitmask if
>>> bitfields are an eyesore here.
>>
>> "unsigned long rsvd : ((sizeof(unsigned long) * 8) - 2);"
>>
>>is an eyesore that defines exactly the same as the two lines alone
>>
>> unsigned long ubcfi_en : 1;
>> unsigned long ubcfi_locked : 1;
>>
>>That one should be removed.
>>
>>If we have only 4 bits in 4/8 bytes, then bitfields do generate worse
>>code than 4 bools and a 0/4 byte hole. The struct size stays the same.
>>
>>I don't care much about the switch to bools, though, because this code
>>is not called often.
>
> I'll remove the bitfields, have single `unsigned long cfi_control_state`
> And do `#define RISCV_UBCFI_EN 1` and so on.
I might have seemed too much against the bitfieds, sorry. I am against
the rsvd fields, because it is a pointless cognitive overhead and even
this series already had a bug in them.
#defines should generate the same code as bitfields (worse than bools),
so the source code is really a matter of personal preference.
(I do prefer bitfields.)
>>>>> @@ -262,3 +292,83 @@ void shstk_release(struct task_struct *tsk)
>>>>> +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 (!cpu_supports_shadow_stack() ||
>>>>> + !is_shstk_enabled(task) || arg != 0)
>>>>> + return -EINVAL;
>>>>
>>>>The task might want to prevent shadow stack from being enabled?
>>>
>>> But Why would it want to do that? Task can simply not issue the prctl. There
>>> are glibc tunables as well using which it can be disabled.
>>
>>The task might do it as some last resort to prevent a buggy code from
>>enabling shadow stacks that would just crash. Or whatever complicated
>>reason userspace can think of.
>>
>>It's more the other way around. I wonder why we're removing this option
>>when we don't really care what userspace does to itself.
>>I think it's complicating the kernel without an obvious gain.
>
> It just feels wierd. There isn't anything like this for other features lit-up
> via envcfg. Does hwprobe allow this on per-task basis? I'll look into it.
I think PMM doesn't allow to lock and the rest don't seem configurable
from userspace.
It's not that important and we hopefully won't be breaking any userspace
if we decided to allow it later, so I'm fine with this version.
