riscv/cfi: Adjust prctl numbers to match glibc cfi-dev branch ABI · Pull Request !6701 · anolis/cloud-kernel

This series introduces user-mode Control-Flow Integrity (CFI) support for RISC-V, covering both shadow stack and landing pad mechanisms, along with the required kernel task state handling, signal delivery support, fork/clone inheritance, and configuration plumbing.

Highlights
1. CFI Extension Support
Adds support for RISC-V user-mode CFI extensions:
zicfilp for landing-pad enforcement
zicfiss for shadow-stack protection
This series also picks up Samuel Holland’s envcfg changes.
If those patches are applied independently, they should be removed from this series.
2. Enablement Model
To preserve compatibility and avoid breaking existing binaries, the kernel does not enable CFI CPU extensions by default.
Instead, CFI is exposed via a prctl() interface that allows userspace to enable, disable, or lock shadow stack / landing pad support for a task.
This lets the userspace loader inspect whether all objects in the process address space were compiled with CFI support before enabling the feature.
If a later dlopen() loads a library without CFI support, userspace may either:
disable the feature, or
terminate the task if the policy requires strict CFI coverage.
3. clone / fork Semantics
CFI state is inherited across clone() and fork().
Since the shadow stack is part of virtual memory and is writable only through a restricted set of shadow-stack instructions, the kernel ensures it becomes read-only on fork/clone and is COWed on faults caused by sspush, sspopchk, or ssamoswap.
If CLONE_VM is specified and shadow stack is enabled, the kernel will automatically allocate a shadow stack for the clone.
4. map_shadow_stack System Call
Implements support for the map_shadow_stack syscall on RISC-V as well.
This allows userspace to explicitly map shadow-stack memory, which is useful for managing multiple execution contexts within a single thread (e.g. green threads or user-level schedulers).
5. Signal Handling
When shadow stack is enabled, signal delivery and sigreturn require extra control-flow protection.
To prevent hijacking via the signal return window, the kernel:
places a token on the shadow stack before delivering a signal
stores the token address in sigcontext
On sigreturn, the kernel fetches the token address from sigcontext, validates it against the shadow stack token, and only then allows the return to succeed.
Compatibility is handled using the dynamic sigcontext management model previously introduced for vector support.
The code is also lightly refactored to make future sigcontext management easier, following suggestions from Andy Chiu (SiFive).
6. Kconfig / Build Support
Introduces CONFIG_RISCV_USER_CFI, a new Kconfig option enabling user-mode CFI support on RISC-V.
This option is only visible when the toolchain supports both shadow stack and landing pad features.
This restriction is intentional, because vDSO will also need to be built with CFI support in the future.
vDSO build patches are not included yet, since the landing-pad labeling scheme for user-mode runtime is still under discussion.

GVPanolis/cloud-kernel

搜索帮助

GVP anolis/cloud-kernel