2025-03-20T16:09:12-07:00, Deepak Gupta debug@rivosinc.com:
On Thu, Mar 20, 2025 at 3:24 PM Radim Krčmář rkrcmar@ventanamicro.com wrote:
2025-03-14T14:39:38-07:00, Deepak Gupta debug@rivosinc.com:
Expose a new register type NT_RISCV_USER_CFI for risc-v cfi status and state. Intentionally both landing pad and shadow stack status and state are rolled into cfi state. Creating two different NT_RISCV_USER_XXX would not be useful and wastage of a note type. Enabling or disabling of feature is not allowed via ptrace set interface. However setting `elp` state or setting shadow stack pointer are allowed via ptrace set interface. It is expected `gdb` might have use to fixup `elp` state or `shadow stack` pointer.
Signed-off-by: Deepak Gupta debug@rivosinc.com
diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h index 659ea3af5680..e6571fba8a8a 100644 @@ -131,6 +131,24 @@ struct __sc_riscv_cfi_state { unsigned long ss_ptr; /* shadow stack pointer */ };
+struct __cfi_status {
/* indirect branch tracking state */__u64 lp_en : 1;__u64 lp_lock : 1;__u64 elp_state : 1;/* shadow stack status */__u64 shstk_en : 1;__u64 shstk_lock : 1;I remember there was deep hatred towards bitfields in the Linux community, have things changes?
hmm. I didn't know about the strong hatred.
There is a good reason for it. :)
The C standard left important behavior as implementation-specific (by mistake, I hope). I do like bitfields, but you have to be extra careful when working with them.
Although I can see lots of examples of this pattern in existing kernel code. No strong feelings on my side, I can change this and have it single 64bit field and accessed via bitmasks.
This is uapi and bitfields do not specify the internal representation. A program compiled at a different time can see completely different order of the bitfields, so the uapi would break.
We cannot use bitfields here.