Re: [PATCH v23 00/28] riscv control-flow integrity for usermode

[Paul Walmsley <pjw@kernel.org>]

On Thu, 27 Nov 2025, patchwork-bot+linux-riscv@kernel.org wrote:

> This series was applied to riscv/linux.git (for-next)
> by Paul Walmsley <pjw@kernel.org>:
> 

[ the RISC-V CFI patch series ]

> 
> Here is the summary with links:
>   - [v23,01/28] mm: VM_SHADOW_STACK definition for riscv
>     https://git.kernel.org/riscv/c/ae8460ac9db2
>   - [v23,02/28] dt-bindings: riscv: zicfilp and zicfiss in dt-bindings (extensions.yaml)
>     https://git.kernel.org/riscv/c/b32ccfc268db
>   - [v23,03/28] riscv: zicfiss / zicfilp enumeration
>     https://git.kernel.org/riscv/c/55a811a7f304
>   - [v23,04/28] riscv: zicfiss / zicfilp extension csr and bit definitions
>     https://git.kernel.org/riscv/c/92c96b16548e
>   - [v23,05/28] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit
>     https://git.kernel.org/riscv/c/7720cdd21962
>   - [v23,06/28] riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE
>     https://git.kernel.org/riscv/c/e60eb198b13d
>   - [v23,07/28] riscv/mm: manufacture shadow stack pte
>     https://git.kernel.org/riscv/c/f8fcb7b5bf30
>   - [v23,08/28] riscv/mm: teach pte_mkwrite to manufacture shadow stack PTEs
>     https://git.kernel.org/riscv/c/0276a5ea1105
>   - [v23,09/28] riscv/mm: write protect and shadow stack
>     https://git.kernel.org/riscv/c/ae615676bc37
>   - [v23,10/28] riscv/mm: Implement map_shadow_stack() syscall
>     https://git.kernel.org/riscv/c/d291fd38f841
>   - [v23,11/28] riscv/shstk: If needed allocate a new shadow stack on clone
>     https://git.kernel.org/riscv/c/d209ea2fa4bb
>   - [v23,12/28] riscv: Implements arch agnostic shadow stack prctls
>     https://git.kernel.org/riscv/c/8b49f512abc2
>   - [v23,13/28] prctl: arch-agnostic prctl for indirect branch tracking
>     https://git.kernel.org/riscv/c/3363a8d1044e
>   - [v23,14/28] riscv: Implements arch agnostic indirect branch tracking prctls
>     https://git.kernel.org/riscv/c/0177891ccdb7
>   - [v23,15/28] riscv/traps: Introduce software check exception and uprobe handling
>     https://git.kernel.org/riscv/c/6f71171a7448
>   - [v23,16/28] riscv: signal: abstract header saving for setup_sigcontext
>     (no matching commit)
>   - [v23,17/28] riscv/signal: save and restore of shadow stack for signal
>     https://git.kernel.org/riscv/c/4f9da7ad3478
>   - [v23,18/28] riscv/kernel: update __show_regs to print shadow stack register
>     https://git.kernel.org/riscv/c/320c96a55d73
>   - [v23,19/28] riscv/ptrace: riscv cfi status and state via ptrace and in core files
>     https://git.kernel.org/riscv/c/7a39f89a817e
>   - [v23,20/28] riscv/hwprobe: zicfilp / zicfiss enumeration in hwprobe
>     https://git.kernel.org/riscv/c/c09b490a9267
>   - [v23,21/28] riscv: kernel command line option to opt out of user cfi
>     https://git.kernel.org/riscv/c/6e0dc40ceb45
>   - [v23,22/28] riscv: enable kernel access to shadow stack memory via FWFT sbi call
>     https://git.kernel.org/riscv/c/dfd087078357
>   - [v23,23/28] arch/riscv: compile vdso with landing pad and shadow stack note
>     https://git.kernel.org/riscv/c/2cfe57e3bd9b
>   - [v23,24/28] arch/riscv: dual vdso creation logic and select vdso based on hw
>     https://git.kernel.org/riscv/c/418316aa61e8
>   - [v23,25/28] riscv: create a config for shadow stack and landing pad instr support
>     https://git.kernel.org/riscv/c/c5f5ce714457
>   - [v23,26/28] riscv: Documentation for landing pad / indirect branch tracking
>     https://git.kernel.org/riscv/c/73d0ccec35b8
>   - [v23,27/28] riscv: Documentation for shadow stack on riscv
>     https://git.kernel.org/riscv/c/6b8214c8cbd6
>   - [v23,28/28] kselftest/riscv: kselftest for user mode cfi
>     https://git.kernel.org/riscv/c/0f226cf6026f

As I noted with the SSE series (before we removed it from for-next), I may 
not ultimately send this in a PR this merge window, for several reasons.  
The series has been around for a while, and although I know some vendors 
have tested it privately, I'd really like to have more public testing of 
this code, particularly on hardware emulation platforms or unreleased 
silicon.  It would be good to see some Tested-by:s. 

Thanks to everyone who has helped test this so far over the past few weeks 
- particularly Joel Stanley of TensTorrent.


- Paul