lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b82ffcca-3173-8c07-4a8a-c42d8d092a72@kernel.org>
Date: Thu, 27 Nov 2025 14:14:03 -0700 (MST)
From: Paul Walmsley <pjw@...nel.org>
To: linux-riscv@...ts.infradead.org
cc: Deepak Gupta <debug@...osinc.com>, tglx@...utronix.de, mingo@...hat.com, 
    bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, 
    akpm@...ux-foundation.org, Liam.Howlett@...cle.com, vbabka@...e.cz, 
    lorenzo.stoakes@...cle.com, paul.walmsley@...ive.com, palmer@...belt.com, 
    aou@...s.berkeley.edu, conor@...nel.org, robh@...nel.org, 
    krzk+dt@...nel.org, arnd@...db.de, brauner@...nel.org, 
    peterz@...radead.org, oleg@...hat.com, ebiederm@...ssion.com, 
    kees@...nel.org, corbet@....net, shuah@...nel.org, jannh@...gle.com, 
    conor+dt@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com, 
    boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, 
    a.hindborg@...nel.org, aliceryhl@...gle.com, tmgross@...ch.edu, 
    lossin@...nel.org, linux-kernel@...r.kernel.org, 
    linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, 
    devicetree@...r.kernel.org, linux-arch@...r.kernel.org, 
    linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org, 
    alistair.francis@....com, richard.henderson@...aro.org, jim.shu@...ive.com, 
    andybnac@...il.com, kito.cheng@...ive.com, charlie@...osinc.com, 
    atishp@...osinc.com, evan@...osinc.com, cleger@...osinc.com, 
    alexghiti@...osinc.com, samitolvanen@...gle.com, broonie@...nel.org, 
    rick.p.edgecombe@...el.com, rust-for-linux@...r.kernel.org, 
    zong.li@...ive.com, david@...hat.com, cmirabil@...hat.com
Subject: Re: [PATCH v23 00/28] riscv control-flow integrity for usermode

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

> This series was applied to riscv/linux.git (for-next)
> by Paul Walmsley <pjw@...nel.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ