[GIT PULL] RISC-V updates for v7.0

[GIT PULL] RISC-V updates for v7.0

[Paul Walmsley]

[-- Attachment #1: Type: text/plain, Size: 13670 bytes --]

Linus,

Please pull these RISC-V updates for v7.0.  The primary new feature
here is support for CFI in user processes.  This feature has been
tested by a set of RISC-V community participants, including by CPU
IP/hardware vendors and by a major Linux distribution.  Other changes
are described in the signed tag.

The code in this PR has been sitting in linux-next for a few weeks.  I
did repush some of the vector ptrace patches a few days ago to fix a
missing Signed-off-by: tag (thanks Mark); no code was changed during
the repush.


thanks,

- Paul


The following changes since commit 28a12ef366ecb118db19b92120a07b0491c1958e:

  errata/sifive: remove unreliable warn_miss_errata (2026-01-25 21:09:04 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux tags/riscv-for-linus-7.0-mw1

for you to fetch changes up to 18be4ca5cb4e5a86833de97d331f5bc14a6c5a6d:

  riscv: lib: optimize strlen loop efficiency (2026-02-09 15:27:33 -0700)

----------------------------------------------------------------
RISC-V updates for v7.0

- Add support for control flow integrity for userspace processes.
  This is based on the standard RISC-V ISA extensions Zicfiss and
  Zicfilp

- Improve ptrace behavior regarding vector registers, and add some selftests

- Optimize our strlen() assembly

- Enable the ISO-8859-1 code page as built-in, similar to ARM64, for EFI
  volume mounting

- Clean up some code slightly, including defining copy_user_page() as
  copy_page() rather than memcpy(), aligning us with other
  architectures; and using max3() to slightly simplify an expression
  in riscv_iommu_init_check()

----------------------------------------------------------------
Deepak Gupta (26):
      mm: add VM_SHADOW_STACK definition for riscv
      dt-bindings: riscv: document zicfilp and zicfiss in extensions.yaml
      riscv: zicfiss / zicfilp enumeration
      riscv: add Zicfiss / Zicfilp extension CSR and bit definitions
      riscv: Add usercfi state for task and save/restore of CSR_SSP on trap entry/exit
      riscv/mm: ensure PROT_WRITE leads to VM_READ | VM_WRITE
      riscv/mm: manufacture shadow stack ptes
      riscv/mm: teach pte_mkwrite to manufacture shadow stack PTEs
      riscv/mm: update write protect to work on shadow stacks
      riscv/mm: Implement map_shadow_stack() syscall
      riscv/shstk: If needed allocate a new shadow stack on clone
      riscv: Implement arch-agnostic shadow stack prctls
      prctl: add arch-agnostic prctl()s for indirect branch tracking
      riscv: Implement indirect branch tracking prctls
      riscv/traps: Introduce software check exception and uprobe handling
      riscv/signal: save and restore the shadow stack on a signal
      riscv/kernel: update __show_regs() to print shadow stack register
      riscv/ptrace: expose riscv CFI status and state via ptrace and in core files
      riscv/hwprobe: add zicfilp / zicfiss enumeration in hwprobe
      riscv: add kernel command line option to opt out of user CFI
      riscv: enable kernel access to shadow stack memory via the FWFT SBI call
      arch/riscv: add dual vdso creation logic and select vdso based on hw
      riscv: create a Kconfig fragment for shadow stack and landing pad support
      riscv: add documentation for landing pad / indirect branch tracking
      riscv: add documentation for shadow stack
      kselftest/riscv: add kselftest for user mode CFI

Feng Jiang (1):
      riscv: lib: optimize strlen loop efficiency

Florian Schmaus (1):
      riscv: mm: define copy_user_page() as copy_page()

Ilya Mamay (1):
      riscv: ptrace: return ENODATA for inactive vector extension

Javier Carrasco (1):
      riscv: defconfig: enable NLS_ISO8859_1

Jim Shu (1):
      arch/riscv: compile vdso with landing pad and shadow stack note

Markus Elfring (1):
      iommu/riscv: Simplify maximum determination in riscv_iommu_init_check()

Paul Walmsley (1):
      riscv: hwprobe: add support for RISCV_HWPROBE_KEY_IMA_EXT_1

Sergey Matyukevich (8):
      riscv: vector: init vector context with proper vlenb
      riscv: csr: define vtype register elements
      riscv: ptrace: validate input vector csr registers
      selftests: riscv: test ptrace vector interface
      selftests: riscv: verify initial vector state with ptrace
      selftests: riscv: verify syscalls discard vector context
      selftests: riscv: verify ptrace rejects invalid vector csr inputs
      selftests: riscv: verify ptrace accepts valid vector csr values

Thomas Weißschuh (1):
      selftests: riscv: vstate_exec_nolibc: Use the regular prctl() function

 Documentation/admin-guide/kernel-parameters.txt    |   8 +
 Documentation/arch/riscv/hwprobe.rst               |   6 +-
 Documentation/arch/riscv/index.rst                 |   2 +
 Documentation/arch/riscv/zicfilp.rst               | 122 +++
 Documentation/arch/riscv/zicfiss.rst               | 194 +++++
 .../devicetree/bindings/riscv/extensions.yaml      |  14 +
 arch/riscv/Kconfig                                 |  22 +
 arch/riscv/Makefile                                |   8 +-
 arch/riscv/configs/defconfig                       |   2 +-
 arch/riscv/configs/hardening.config                |   4 +
 arch/riscv/include/asm/asm-prototypes.h            |   1 +
 arch/riscv/include/asm/assembler.h                 |  44 +
 arch/riscv/include/asm/cpufeature.h                |  12 +
 arch/riscv/include/asm/csr.h                       |  31 +
 arch/riscv/include/asm/entry-common.h              |   2 +
 arch/riscv/include/asm/hwcap.h                     |   2 +
 arch/riscv/include/asm/hwprobe.h                   |   3 +-
 arch/riscv/include/asm/mman.h                      |  26 +
 arch/riscv/include/asm/mmu_context.h               |   7 +
 arch/riscv/include/asm/page.h                      |   3 +-
 arch/riscv/include/asm/pgtable.h                   |  30 +-
 arch/riscv/include/asm/processor.h                 |   1 +
 arch/riscv/include/asm/thread_info.h               |   3 +
 arch/riscv/include/asm/usercfi.h                   |  97 +++
 arch/riscv/include/asm/vdso.h                      |  13 +-
 arch/riscv/include/uapi/asm/hwprobe.h              |   4 +
 arch/riscv/include/uapi/asm/ptrace.h               |  34 +
 arch/riscv/include/uapi/asm/sigcontext.h           |   1 +
 arch/riscv/kernel/Makefile                         |   2 +
 arch/riscv/kernel/asm-offsets.c                    |  10 +
 arch/riscv/kernel/cpufeature.c                     |  25 +
 arch/riscv/kernel/entry.S                          |  38 +
 arch/riscv/kernel/head.S                           |  27 +
 arch/riscv/kernel/process.c                        |  27 +-
 arch/riscv/kernel/ptrace.c                         | 193 ++++-
 arch/riscv/kernel/signal.c                         |  86 ++
 arch/riscv/kernel/sys_hwprobe.c                    | 170 ++--
 arch/riscv/kernel/sys_riscv.c                      |  10 +
 arch/riscv/kernel/traps.c                          |  54 ++
 arch/riscv/kernel/usercfi.c                        | 542 ++++++++++++
 arch/riscv/kernel/vdso.c                           |   7 +
 arch/riscv/kernel/vdso/Makefile                    |  40 +-
 arch/riscv/kernel/vdso/flush_icache.S              |   4 +
 arch/riscv/kernel/vdso/gen_vdso_offsets.sh         |   4 +-
 arch/riscv/kernel/vdso/getcpu.S                    |   4 +
 arch/riscv/kernel/vdso/note.S                      |   3 +
 arch/riscv/kernel/vdso/rt_sigreturn.S              |   4 +
 arch/riscv/kernel/vdso/sys_hwprobe.S               |   4 +
 arch/riscv/kernel/vdso/vgetrandom-chacha.S         |   5 +-
 arch/riscv/kernel/vdso_cfi/Makefile                |  25 +
 arch/riscv/kernel/vdso_cfi/vdso-cfi.S              |  11 +
 arch/riscv/kernel/vector.c                         |  12 +-
 arch/riscv/lib/strlen.S                            |   8 +-
 arch/riscv/mm/init.c                               |   2 +-
 arch/riscv/mm/pgtable.c                            |  16 +
 drivers/iommu/riscv/iommu.c                        |   8 +-
 include/linux/cpu.h                                |   4 +
 include/linux/mm.h                                 |   5 +-
 include/uapi/linux/elf.h                           |   2 +
 include/uapi/linux/prctl.h                         |  27 +
 kernel/sys.c                                       |  30 +
 tools/testing/selftests/riscv/Makefile             |   2 +-
 tools/testing/selftests/riscv/cfi/.gitignore       |   2 +
 tools/testing/selftests/riscv/cfi/Makefile         |  23 +
 tools/testing/selftests/riscv/cfi/cfi_rv_test.h    |  82 ++
 tools/testing/selftests/riscv/cfi/cfitests.c       | 173 ++++
 tools/testing/selftests/riscv/cfi/shadowstack.c    | 385 +++++++++
 tools/testing/selftests/riscv/cfi/shadowstack.h    |  27 +
 tools/testing/selftests/riscv/hwprobe/which-cpus.c |  18 +-
 tools/testing/selftests/riscv/vector/.gitignore    |   2 +
 tools/testing/selftests/riscv/vector/Makefile      |  10 +-
 tools/testing/selftests/riscv/vector/v_helpers.c   |  23 +
 tools/testing/selftests/riscv/vector/v_helpers.h   |   2 +
 .../selftests/riscv/vector/validate_v_ptrace.c     | 915 +++++++++++++++++++++
 .../selftests/riscv/vector/vstate_exec_nolibc.c    |   8 +-
 75 files changed, 3655 insertions(+), 122 deletions(-)
 create mode 100644 Documentation/arch/riscv/zicfilp.rst
 create mode 100644 Documentation/arch/riscv/zicfiss.rst
 create mode 100644 arch/riscv/configs/hardening.config
 create mode 100644 arch/riscv/include/asm/mman.h
 create mode 100644 arch/riscv/include/asm/usercfi.h
 create mode 100644 arch/riscv/kernel/usercfi.c
 create mode 100644 arch/riscv/kernel/vdso_cfi/Makefile
 create mode 100644 arch/riscv/kernel/vdso_cfi/vdso-cfi.S
 create mode 100644 tools/testing/selftests/riscv/cfi/.gitignore
 create mode 100644 tools/testing/selftests/riscv/cfi/Makefile
 create mode 100644 tools/testing/selftests/riscv/cfi/cfi_rv_test.h
 create mode 100644 tools/testing/selftests/riscv/cfi/cfitests.c
 create mode 100644 tools/testing/selftests/riscv/cfi/shadowstack.c
 create mode 100644 tools/testing/selftests/riscv/cfi/shadowstack.h
 create mode 100644 tools/testing/selftests/riscv/vector/validate_v_ptrace.c

vmlinux size differences in bytes (from 28a12ef366ec):
  text   data bss    dec   hex filename                             
 +6290  +8892  +8 +15190 +3b56 vmlinux.defconfig.gcc-15             
 +5684  +9668  +8 +15360 +3c00 vmlinux.nosmp_defconfig.gcc-15       
 +1672  +2720   .  +4392 +1128 vmlinux.rv32_defconfig.gcc-15        
 +1188   +288   .  +1476  +5c4 vmlinux.rv32_nosmp_defconfig.gcc-15  
 +1628   +128   .  +1756  +6dc vmlinux.nommu_virt_defconfig.gcc-15  
  +692  +3864   .  +4556 +11cc vmlinux.defconfig.clang-20           
 +1024   +256   .  +1280  +500 vmlinux.nosmp_defconfig.clang-20     
  +940  +2616   .  +3556  +de4 vmlinux.rv32_defconfig.clang-20      
 +1188   +288   .  +1476  +5c4 vmlinux.rv32_nosmp_defconfig.clang-20
 +1762  -3904   .  -2142  -85e vmlinux.nommu_virt_defconfig.clang-20
 +1620  +3624   .  +5244 +147c vmlinux.defconfig.gcc-14             
 +1380   +240   .  +1620  +654 vmlinux.nosmp_defconfig.gcc-14       
 +1604  +2752   .  +4356 +1104 vmlinux.rv32_defconfig.gcc-14        
 +1192   +320   .  +1512  +5e8 vmlinux.rv32_nosmp_defconfig.gcc-14  
 +1616   +448   .  +2064  +810 vmlinux.nommu_virt_defconfig.gcc-14  
  +980  +3576   .  +4556 +11cc vmlinux.defconfig.clang-19           
 +1228    -32   .  +1196  +4ac vmlinux.nosmp_defconfig.clang-19     
  +904  +2656   .  +3560  +de8 vmlinux.rv32_defconfig.clang-19      
 +1204   +288   .  +1492  +5d4 vmlinux.rv32_nosmp_defconfig.clang-19
 +1770  -7744   .  -5974 -1756 vmlinux.nommu_virt_defconfig.clang-19
 +1352  +3688   .  +5040 +13b0 vmlinux.defconfig.gcc-13             
 +1168   +224   .  +1392  +570 vmlinux.nosmp_defconfig.gcc-13       
 +1416  +2752   .  +4168 +1048 vmlinux.rv32_defconfig.gcc-13        
  +944   +320   .  +1264  +4f0 vmlinux.rv32_nosmp_defconfig.gcc-13  
 +1568   +384   .  +1952  +7a0 vmlinux.nommu_virt_defconfig.gcc-13  
  +836  +3832   .  +4668 +123c vmlinux.defconfig.clang-18           
 +1228   +224   .  +1452  +5ac vmlinux.nosmp_defconfig.clang-18     
  +896  +2648   .  +3544  +dd8 vmlinux.rv32_defconfig.clang-18      
 +1252   +320   .  +1572  +624 vmlinux.rv32_nosmp_defconfig.clang-18
 +1762   +256   .  +2018  +7e2 vmlinux.nommu_virt_defconfig.clang-18
 +1500  +3752   .  +5252 +1484 vmlinux.defconfig.gcc-12             
 +1228   +304   .  +1532  +5fc vmlinux.nosmp_defconfig.gcc-12       
 +1324  +2752   .  +4076  +fec vmlinux.rv32_defconfig.gcc-12        
  +988   +352   .  +1340  +53c vmlinux.rv32_nosmp_defconfig.gcc-12  
 +1580   +384   .  +1964  +7ac vmlinux.nommu_virt_defconfig.gcc-12  
 +1144  +3832   .  +4976 +1370 vmlinux.defconfig.clang-17           
 +1716   +224   .  +1940  +794 vmlinux.nosmp_defconfig.clang-17     
 +1520  +2616   .  +4136 +1028 vmlinux.rv32_defconfig.clang-17      
 +1884   +352   .  +2236  +8bc vmlinux.rv32_nosmp_defconfig.clang-17
 +2134 +12736   . +14870 +3a16 vmlinux.nommu_virt_defconfig.clang-17
 +1524  +3432   .  +4956 +135c vmlinux.defconfig.gcc-11             
  +996    -32   .   +964  +3c4 vmlinux.nosmp_defconfig.gcc-11       
 +1460  +2784   .  +4244 +1094 vmlinux.rv32_defconfig.gcc-11        
 +1084   +320   .  +1404  +57c vmlinux.rv32_nosmp_defconfig.gcc-11  
 +1564   +128   .  +1692  +69c vmlinux.nommu_virt_defconfig.gcc-11  
 +1028   +224   .  +1252  +4e4 vmlinux.allnoconfig.gcc-14           
 +8858  +2172   . +11030 +2b16 vmlinux.allmodconfig.gcc-14          
  +768    -32   .   +736  +2e0 vmlinux.allnoconfig.clang-19         
+26214  +1404  -8 +27610 +6bda vmlinux.allmodconfig.clang-19        

Re: [GIT PULL] RISC-V updates for v7.0

[Linus Torvalds]

On Thu, 12 Feb 2026 at 15:39, Paul Walmsley <pjw@kernel.org> wrote:
>
> Deepak Gupta (26):
>       prctl: add arch-agnostic prctl()s for indirect branch tracking

Hmm. In the meantime, I had pulled the RSEQ time slice extensions
stuff first, so what happened was that these prctl numbers got bumped
up from 79-81 to 80-82.

I note that it looks like linux-next ended up merging things in a
different order, and so instead left the indirect branch status prctls
alone, and instead modified the RSEQ one.

Just letting everybody involved know - maybe this was obvious to
people, and maybe this came as a surprise.

And only very tangentially related: I think the indirect branch
locking could have been just a separate bit from the enable bit. I
don't see why it needed separate prctls for "set status" and "set
lock".

On a similar theme: why is it called "indir_br_lp"? That's a horrible name.

This was supposed to be architecture-neutral, but I get the feeling
that "lp" does not stand for "Long Play" and has nothing to do with
12-inch vinyl records.

I think it probably is shorthand for "lpad", which is RISC-V thing.
Which is complete nonsense for something that is documented to be
architecture-neutral.

So the naming is wrong, and needs to be fixed. So maybe just as well
that the numbers also changed.

In other words: I've pulled this, but I expect this to be fixed asap.

               Linus

Re: [GIT PULL] RISC-V updates for v7.0

[pr-tracker-bot]

The pull request you sent on Thu, 12 Feb 2026 16:39:48 -0700 (MST):

> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux tags/riscv-for-linus-7.0-mw1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cee73b1e840c154f64ace682cb477c1ae2e29cc4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] RISC-V updates for v7.0

[Paul Walmsley]

On Thu, 12 Feb 2026, Linus Torvalds wrote:

> On Thu, 12 Feb 2026 at 15:39, Paul Walmsley <pjw@kernel.org> wrote:
> >
> > Deepak Gupta (26):
> >       prctl: add arch-agnostic prctl()s for indirect branch tracking
> 
> Hmm. In the meantime, I had pulled the RSEQ time slice extensions
> stuff first, so what happened was that these prctl numbers got bumped
> up from 79-81 to 80-82.
> 
> I note that it looks like linux-next ended up merging things in a
> different order, and so instead left the indirect branch status prctls
> alone, and instead modified the RSEQ one.
> 
> Just letting everybody involved know - maybe this was obvious to
> people, and maybe this came as a surprise.

Thanks for the heads-up; shouldn't be a problem.

> And only very tangentially related: I think the indirect branch
> locking could have been just a separate bit from the enable bit. I
> don't see why it needed separate prctls for "set status" and "set
> lock".

Will think this through and respond back.

> On a similar theme: why is it called "indir_br_lp"? That's a horrible name.
> 
> This was supposed to be architecture-neutral, but I get the feeling
> that "lp" does not stand for "Long Play" and has nothing to do with
> 12-inch vinyl records.
> 
> I think it probably is shorthand for "lpad", which is RISC-V thing.
> Which is complete nonsense for something that is documented to be
> architecture-neutral.

RISC-V didn't invent that term; here are some earlier CFI-related uses:

* ARM (2019): https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Providing%20protection%20for%20complex%20software.pdf
* LWN (2022): https://lwn.net/Articles/900099/
* FineIBT (2023): https://cs.brown.edu/~vpk/papers/fineibt.raid23.pdf

If you're okay with keeping the term "landing pad," we could get rid of 
the "LP" and use something like "branch_landing_pad" instead.  Or 
perhaps "verified_branch_target" could be another option.  It would be 
nice to avoid using IBT or BTI, since those are definitely associated with 
specific architectures.  Any preference?

> In other words: I've pulled this, but I expect this to be fixed asap.

Will do, once we stop bikeshedding on the name :-)


thanks

- Paul

Re: [GIT PULL] RISC-V updates for v7.0

[Linus Torvalds]

On Fri, 13 Feb 2026 at 16:23, Paul Walmsley <pjw@kernel.org> wrote:
>
> > I think it probably is shorthand for "lpad", which is RISC-V thing.
> > Which is complete nonsense for something that is documented to be
> > architecture-neutral.
>
> RISC-V didn't invent that term; here are some earlier CFI-related uses:
>
> * ARM (2019): https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Providing%20protection%20for%20complex%20software.pdf
> * LWN (2022): https://lwn.net/Articles/900099/
> * FineIBT (2023): https://cs.brown.edu/~vpk/papers/fineibt.raid23.pdf
>
> If you're okay with keeping the term "landing pad," we could get rid of
> the "LP" and use something like "branch_landing_pad" instead.

Oh, ok. "landing pad" makes sense. "lp" didn't.

I absolutely detest the industry practice of making crazy acronyms
that make no sense - and then every company makes their *own* crazy
acronym to make things worse.

Please just write it out. It's a few extra characters, but maybe it
then makes people understand what it is all about.

When it's called "indir_br_lp", it's just line noise. The most
understandable part of that line noise is "indir", but that's also the
least relevant - noody does this all for direct branches anyway, so
the "indir" part is arguably the least useful part of it.

So yeah, something like "branch_landing_pad" at least sounds like it's
meant for human consumption.

I would have expected there to be some industry standard naming for
this, but if there is, I sure can't find it. Everybody carves out
their own small space of "control flow integrity" and gives it a TLA.

So I can only find letter jumbles that are all different for different
architectures. Oh well.

I do wonder if we should do something like the existing speculation
control prctl does: we have a notion of "prctl_spec_ctrl", and it then
has "subcontrols" for the individual parts (ie PR_SPEC_STORE_BYPASS /
PR_SPEC_INDIRECT_BRANCH / PR_SPEC_L1D_FLUSH).

Although it looks like only PR_SPEC_STORE_BYPASS ends up being
somewhat cross-architecture.

IOW, I get the feeling that we should have a "control flow integrity" prctl.

Because arguably the shadow-stack feature would have fit under that
umbrella - instead of us now having multiple different prctrls.

One subcontrol of that that control flow integrity prctrl to be set
(and queried, and locked) would then be that "branch_landing_pad" bit
(aka arm64 BTI, x86 IBT, and apparently Zicfilp if you're a RISC-V
person).

I guess with names like "Zicfilp" - it really rolls off the tongue,
doesn't it - the notion of "human readable" might be a foreign concept
to some RISC-V designers. They really took that "TLA's are bad" as a
challenge, went "hold my beer", and came up with an even *worse*
industry practice.

Can we please be a force for good in the industry, and try to use
names and identifiers that make sense to humans?

And maybe be a bit forward-thinking so that the *next* time somebody
wants to do a prctrl for some flow control setting, we already have
the infrastructure in place?

                  Linus

Re: [GIT PULL] RISC-V updates for v7.0

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Fri, Feb 13, 2026 at 05:23:41PM -0700, Paul Walmsley wrote:
> On Thu, 12 Feb 2026, Linus Torvalds wrote:
> > On Thu, 12 Feb 2026 at 15:39, Paul Walmsley <pjw@kernel.org> wrote:

> > And only very tangentially related: I think the indirect branch
> > locking could have been just a separate bit from the enable bit. I
> > don't see why it needed separate prctls for "set status" and "set
> > lock".

> Will think this through and respond back.

If that's the part I think it is it's following the same pattern as
shadow stacks, originally inherited from x86 then generalised.  We have
a prctl() that configures the feature and any optional flags for it
(it looks like the indirect branches don't have any) and another that
lets userspace lock each flag to it's current state individually.
They're separate prctl()s so you can use the same defines to specify the
features.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] RISC-V updates for v7.0

[Linus Walleij]

On Sat, Feb 14, 2026 at 5:14 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> When it's called "indir_br_lp", it's just line noise. The most
> understandable part of that line noise is "indir", but that's also the
> least relevant - noody does this all for direct branches anyway, so
> the "indir" part is arguably the least useful part of it.
>
> So yeah, something like "branch_landing_pad" at least sounds like it's
> meant for human consumption.

I clearly remember that the the first time we were presented with the BTI
instruction (at a joint Linaro/Ubuntu conference in Budapest) Arnd Bergman
immediately exclaimed, "so you invented the comefrom instruction!"

The thing is a joke, but it's impossible to forget this because it sort of
wires you head to the understanding of what this essentially is. That
joke even has a wikipedia page.
https://en.wikipedia.org/wiki/COMEFROM

Yours,
Linus Walleij

Re: [GIT PULL] RISC-V updates for v7.0

[Linus Torvalds]

On Mon, 16 Feb 2026 at 06:20, Mark Brown <broonie@kernel.org> wrote:
>
> If that's the part I think it is it's following the same pattern as
> shadow stacks, originally inherited from x86 then generalised.

That makes sense. I was looking at the speculation control ones -
which I honestly think are done much better in that they are a bit
more future-proof and won't need yet another random prctl just because
some architecture comes up with a slight variation on a theme.

They don't technically do the locking (the speculation control has a
different kind of locking), but because of how they do things - by
having separate "which control do you want to change", and "how do you
want to change it", it would actually be very natural to make "lock
it" just another thing.

So I actually wish we didn't have that shadow stack prctl - or this
new one - at all, and they'd just use the speculation mitigation
pattern instead.

I think the shadow stack case is probably too late to fix and people
presumably already use it, but maybe it's not too late to fix this new
control flow integrity case?

                 Linus

Re: [GIT PULL] RISC-V updates for v7.0

[Deepak Gupta]

On Mon, Feb 16, 2026 at 01:55:11PM -0800, Linus Torvalds wrote:
>On Mon, 16 Feb 2026 at 06:20, Mark Brown <broonie@kernel.org> wrote:
>>
>> If that's the part I think it is it's following the same pattern as
>> shadow stacks, originally inherited from x86 then generalised.
>
>That makes sense. I was looking at the speculation control ones -
>which I honestly think are done much better in that they are a bit
>more future-proof and won't need yet another random prctl just because
>some architecture comes up with a slight variation on a theme.
>
>They don't technically do the locking (the speculation control has a
>different kind of locking), but because of how they do things - by
>having separate "which control do you want to change", and "how do you
>want to change it", it would actually be very natural to make "lock
>it" just another thing.
>
>So I actually wish we didn't have that shadow stack prctl - or this
>new one - at all, and they'd just use the speculation mitigation
>pattern instead.
>
>I think the shadow stack case is probably too late to fix and people
>presumably already use it, but maybe it's not too late to fix this new
>control flow integrity case?

A little bit of history on this. I was at Intel back when Intel was trying
to enable support for "shadow stack" and "enbranch (branch terminating instr)"
feature. Given no other ISAs at that time had any notion of "shadow stack"
and "indirect branch tracking", IIRC it was advised on list that "shadow
stack" enabling for x86 should be done via arch specific prctl. Yu-cheng/Rick
Edgecombe can correct me if I am missing something here.

"x86 indirect branch tracking" enabling for userspace never made it to kernel
(although most distros when they compile userspace/packages, `endbr64` is
compiled-in so that whenever it lands, enabling is one step away).

Later in 2022 when I started doing work for cfi extensions on RISC-V, I started
with arch-agnostic prctl for enabling shadow stack and branch tracking. I was
hoping that all arches would end up converging on that. Soon Mark Brown sent
out arm's "Guarded Control Stack" (aka shadow stack) which used the
arch-agnostic shadow stack prctl.

So today we have 
- arch specific shadow stack prctl for managing (enable/lock/disable) shadow
   stack on x86

- arch-agnostic prctl for shadow stack management on arm64 and RISC-V


If we land arch-agnostic prctl for enabling branch tracking for userspace as
part of risc-v patches, I am hoping we can leverage that for x86 "branch
tracking enabling" as well. I don't know if "BTI" is enabled for userspace in
the arm64 world but if it isn't then it can use the same prctl. This creates
symmetry and convergence as well between major 3 arches for branch tracking
support.

Furthermore, Control-flow integrity is shadow stack (for backward cfi) and
branch tracking (for forward cfi) both. It'll look odd and ugly (to an extent
it already is because x86 and arm64/riscv use different prctls for shstk) that
shadow stack has its own prctl and we invent new cfi prctl just for branch
tracking.

Ideally, it would have been nicer if we had
`PR_GET/SET_TASK_EXPLOIT_MITIGATIONS` and sub-codes under them to enable all
sort of things like "Manage CFI", "Manage memory tagging", "Manage speculation
control", etc. But things evolved on their own pace at different timelines.

Given that we already have a fragmentation in prctl space, I propose we go for
arch-agnostic branch tracking prctl and let other ISAs implement support as
they go about it.

If you agree, I'll let Paul choose the right name for it (given that indir_lp
isn't a favorite)


>
>                 Linus

Re: [GIT PULL] RISC-V updates for v7.0

[Edgecombe, Rick P]

On Wed, 2026-02-18 at 11:57 -0800, Deepak Gupta wrote:
> Later in 2022 when I started doing work for cfi extensions on RISC-V, I started
> with arch-agnostic prctl for enabling shadow stack and branch tracking. I was
> hoping that all arches would end up converging on that. Soon Mark Brown sent
> out arm's "Guarded Control Stack" (aka shadow stack) which used the
> arch-agnostic shadow stack prctl.
> 
> So today we have 
> - arch specific shadow stack prctl for managing (enable/lock/disable) shadow
>    stack on x86
> 
> - arch-agnostic prctl for shadow stack management on arm64 and RISC-V
> 
> 
> If we land arch-agnostic prctl for enabling branch tracking for userspace as
> part of risc-v patches, I am hoping we can leverage that for x86 "branch
> tracking enabling" as well. I don't know if "BTI" is enabled for userspace in
> the arm64 world but if it isn't then it can use the same prctl. This creates
> symmetry and convergence as well between major 3 arches for branch tracking
> support.

Arm already uses PROT_BTI to enable their landing pad like thing. It doesn't
need a prctl AFAIU. Peterz had been suggesting we do a similar PROT for x86 user
IBT. Although an additional prctl might still be required for x86. We'd have to
actually start taking the patches upstream to see.

> 
> Furthermore, Control-flow integrity is shadow stack (for backward cfi) and
> branch tracking (for forward cfi) both. It'll look odd and ugly (to an extent
> it already is because x86 and arm64/riscv use different prctls for shstk) that
> shadow stack has its own prctl and we invent new cfi prctl just for branch
> tracking.
> 
> Ideally, it would have been nicer if we had
> `PR_GET/SET_TASK_EXPLOIT_MITIGATIONS` and sub-codes under them to enable all
> sort of things like "Manage CFI", "Manage memory tagging", "Manage speculation
> control", etc. But things evolved on their own pace at different timelines.

During shadow stack/lam enabling we tried to create a generic x86 interface for
"per-thread features" with the idea that IBT would also go in there. However,
tglx made a bunch of points[0] against trying to do a universal thing.

After that attempt we kind of gave up and just let them be specific. Although,
it was not appreciated at the time that arm and riscv shadow stack would be so
similar.

I don't think we should have a generic "CFI" control though, because there are
other very different forms of backward edge CFI like PAC.

[0] https://lore.kernel.org/lkml/87zgjjqico.ffs@tglx/

> 
> Given that we already have a fragmentation in prctl space, I propose we go for
> arch-agnostic branch tracking prctl and let other ISAs implement support as
> they go about it.

I think the situation for forward edge isn't the same as shadow stack, where the
features matched so well. At least for ARM. My best guess is that x86 could
possibly use it if/when we get to user IBT. But best guess, would have a PROT
involved too. So that could be different semantics. Sorry, I never looked at
your forward edge patches. I think you don't have a PROT, right?

> 
> If you agree, I'll let Paul choose the right name for it (given that indir_lp
> isn't a favorite)

Re: [GIT PULL] RISC-V updates for v7.0

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Wed, Feb 18, 2026 at 09:58:41PM +0000, Edgecombe, Rick P wrote:
> On Wed, 2026-02-18 at 11:57 -0800, Deepak Gupta wrote:

> > If we land arch-agnostic prctl for enabling branch tracking for userspace as
> > part of risc-v patches, I am hoping we can leverage that for x86 "branch
> > tracking enabling" as well. I don't know if "BTI" is enabled for userspace in
> > the arm64 world but if it isn't then it can use the same prctl. This creates
> > symmetry and convergence as well between major 3 arches for branch tracking
> > support.

BTI has been available to userspace for quite a while now.

> Arm already uses PROT_BTI to enable their landing pad like thing. It doesn't
> need a prctl AFAIU. Peterz had been suggesting we do a similar PROT for x86 user
> IBT. Although an additional prctl might still be required for x86. We'd have to
> actually start taking the patches upstream to see.

Yeah, for arm64 BTI the control is all per page rather than per thread
or process.  Unless I'm forgetting something there's just not a global
control for this in the hardware, it's all keyed off the page tables.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] RISC-V updates for v7.0

[Deepak Gupta]

On Thu, Feb 19, 2026 at 12:01:10AM +0000, Mark Brown wrote:
>On Wed, Feb 18, 2026 at 09:58:41PM +0000, Edgecombe, Rick P wrote:
>> On Wed, 2026-02-18 at 11:57 -0800, Deepak Gupta wrote:
>
>> > If we land arch-agnostic prctl for enabling branch tracking for userspace as
>> > part of risc-v patches, I am hoping we can leverage that for x86 "branch
>> > tracking enabling" as well. I don't know if "BTI" is enabled for userspace in
>> > the arm64 world but if it isn't then it can use the same prctl. This creates
>> > symmetry and convergence as well between major 3 arches for branch tracking
>> > support.
>
>BTI has been available to userspace for quite a while now.

Noted.

>
>> Arm already uses PROT_BTI to enable their landing pad like thing. It doesn't
>> need a prctl AFAIU. Peterz had been suggesting we do a similar PROT for x86 user
>> IBT. Although an additional prctl might still be required for x86. We'd have to
>> actually start taking the patches upstream to see.
>
>Yeah, for arm64 BTI the control is all per page rather than per thread
>or process.  Unless I'm forgetting something there's just not a global
>control for this in the hardware, it's all keyed off the page tables.

Aah this makes sense. This is different from x86 and risc-v. Since BTI is on
per-code page basis, kernel enables if loader (interpreter for executable) and
then likely loader sets PROT_BTI for rest of the user space dependencies.

Re: [GIT PULL] RISC-V updates for v7.0

[Deepak Gupta]

Hi Rick,

Comments inline.

On Wed, Feb 18, 2026 at 09:58:41PM +0000, Edgecombe, Rick P wrote:
>On Wed, 2026-02-18 at 11:57 -0800, Deepak Gupta wrote:
>> Later in 2022 when I started doing work for cfi extensions on RISC-V, I started
>> with arch-agnostic prctl for enabling shadow stack and branch tracking. I was
>> hoping that all arches would end up converging on that. Soon Mark Brown sent
>> out arm's "Guarded Control Stack" (aka shadow stack) which used the
>> arch-agnostic shadow stack prctl.
>>
>> So today we have
>> - arch specific shadow stack prctl for managing (enable/lock/disable) shadow
>>    stack on x86
>>
>> - arch-agnostic prctl for shadow stack management on arm64 and RISC-V
>>
>>
>> If we land arch-agnostic prctl for enabling branch tracking for userspace as
>> part of risc-v patches, I am hoping we can leverage that for x86 "branch
>> tracking enabling" as well. I don't know if "BTI" is enabled for userspace in
>> the arm64 world but if it isn't then it can use the same prctl. This creates
>> symmetry and convergence as well between major 3 arches for branch tracking
>> support.
>
>Arm already uses PROT_BTI to enable their landing pad like thing. It doesn't
>need a prctl AFAIU. Peterz had been suggesting we do a similar PROT for x86 user
>IBT. Although an additional prctl might still be required for x86. We'd have to
>actually start taking the patches upstream to see.

x86 doesn't have any equivalent BTI bit in PTEs to mark code pages. IIRC, it
does have mechanism where a bitmap has to be prepared and each entry in bitmap
encodes whether a page is legacy code page (without `endbr64`) or a modern code
page (with `endbr64`). And CPU will consult this bitmap to suppress the fault.

As of today almost all distros and packages are shipping with
`-fcf-protection=full` compile flag and that means all userspace binaries should
have `endbr64` compiled in (i.e. modern binaries).

To be very specific, anyone using beyond 7.0 kernel (that's where x86 `endbr64`
enabling support will land) is most likely running latest userspace on it. Anyone
who is running old userspace anyways is so behind that its likely plagued with
vulnerabilities that an effort to enable cfi on it may be futile.

So if x86 were to follow arm model and use it's legacy interworking bitmap to
support mix of old (without `endbr64`) and new binaries in task's address space,
I see following problems:

- It'll need support in kernel to prepare and manage readonly bitmap in task's
   address space. Along with code in kernel to support updating bitmap on
   `dlopen` happening in userspace.

- Every indirect call to a legacy binary will lead to an additional load on
   legacy interworking bitmap virt memory and thus will lead to perf issues. So
   even in the case when someone has mix of old and new binaries, they most
   likely won't enable it. Or try to make sure that they have all binaries in
   task's address space with `endbr64` support.

- As of today no one is using legacy interworking bitmap part of Intel CET. And
   I am also not sure how much of this hardware feature has been verified. So
   likely, you may run into issues and errata first.

This is a lot of throwaway work to support a usecase which likely doesn't exist
because most distros anyway compile binaries with `endbr64` and even if such a
use case exist, its perf characteristics will suck quite bad and security
guarantees are also poor (worst of both world).

So my suggestion would be to keep it like shadow stack:

Loader takes a decision whether to enable forward cfi for current task or not
(like it is done for shadow stack)

Hopefully Intel will deprecate legacy interworking part of Intel CET in future
generation(s) and simplify it.

>
>>
>> Furthermore, Control-flow integrity is shadow stack (for backward cfi) and
>> branch tracking (for forward cfi) both. It'll look odd and ugly (to an extent
>> it already is because x86 and arm64/riscv use different prctls for shstk) that
>> shadow stack has its own prctl and we invent new cfi prctl just for branch
>> tracking.
>>
>> Ideally, it would have been nicer if we had
>> `PR_GET/SET_TASK_EXPLOIT_MITIGATIONS` and sub-codes under them to enable all
>> sort of things like "Manage CFI", "Manage memory tagging", "Manage speculation
>> control", etc. But things evolved on their own pace at different timelines.
>
>During shadow stack/lam enabling we tried to create a generic x86 interface for
>"per-thread features" with the idea that IBT would also go in there. However,
>tglx made a bunch of points[0] against trying to do a universal thing.
>
>After that attempt we kind of gave up and just let them be specific. Although,
>it was not appreciated at the time that arm and riscv shadow stack would be so
>similar.
>
>I don't think we should have a generic "CFI" control though, because there are
>other very different forms of backward edge CFI like PAC.
>
>[0] https://lore.kernel.org/lkml/87zgjjqico.ffs@tglx/
>
>>
>> Given that we already have a fragmentation in prctl space, I propose we go for
>> arch-agnostic branch tracking prctl and let other ISAs implement support as
>> they go about it.
>
>I think the situation for forward edge isn't the same as shadow stack, where the
>features matched so well. At least for ARM. My best guess is that x86 could
>possibly use it if/when we get to user IBT. But best guess, would have a PROT
>involved too. So that could be different semantics. Sorry, I never looked at
>your forward edge patches. I think you don't have a PROT, right?
>
>>
>> If you agree, I'll let Paul choose the right name for it (given that indir_lp
>> isn't a favorite)
>

Re: [GIT PULL] RISC-V updates for v7.0

[Edgecombe, Rick P]

On Wed, 2026-02-18 at 17:57 -0800, Deepak Gupta wrote:
> x86 doesn't have any equivalent BTI bit in PTEs to mark code pages. IIRC, it
> does have mechanism where a bitmap has to be prepared and each entry in bitmap
> encodes whether a page is legacy code page (without `endbr64`) or a modern code
> page (with `endbr64`). And CPU will consult this bitmap to suppress the fault.

This might not be the right thread to get into the gory implementation details,
but at a high level, I had looked at two ways to tie it into the ARM interface.
One worked with the bitmap, and the plumbing to connect it to PROT_BTI was
horrible. The other simply handled the #CP exceptions and checked the vma. If
RIP had !PROT_BTI, it cleared the TRACKER bit and continued. It was pretty slick
and small. This of course penalizes any non-IBT DSO that is loaded by an IBT
executable and is targeted by an indirect call. But it wasn't as much of
disaster as you might expect. I have the numbers somewhere.

> 
> As of today almost all distros and packages are shipping with
> `-fcf-protection=full` compile flag and that means all userspace binaries should
> have `endbr64` compiled in (i.e. modern binaries).

This is actually more of a problem than a solution. The automatic CFI enabling
dream didn't quite work. In the end, glibc made the shadow stack feature so you
need to opt-in via TUNABLE env var, instead of opt-out.

> This is a lot of throwaway work to support a usecase which likely doesn't exist
> because most distros anyway compile binaries with `endbr64` and even if such a
> use case exist, its perf characteristics will suck quite bad and security
> guarantees are also poor (worst of both world).
> 
> So my suggestion would be to keep it like shadow stack:
> 
> Loader takes a decision whether to enable forward cfi for current task or not
> (like it is done for shadow stack)
> 
> Hopefully Intel will deprecate legacy interworking part of Intel CET in future
> generation(s) and simplify it.

One of the reasons to use a PROT_BTI type interface was to make it work like ARM
for reasons like up the thread, but also because distro-wide enabling is hard in
the long tail. I think it would be nice to take the learnings from shadow stack
distro enabling and try to make IBT so that it could more safely be turned on
automatically, via a more flexible intermediary step. Like a "mixed mode" that
warns about mismatched executables, but prioritizes not breaking any user
visible behavior. But this is a much larger topic.

But taking a step back, while I'm still keen on doing user IBT, the longer time
goes on, the more it becomes an "if" rather than a "when". You probably
shouldn't count on any of this too much for RISC-V enabling decisions.

Re: [GIT PULL] RISC-V updates for v7.0

[patchwork-bot+linux-riscv]

Hello:

This pull request was applied to riscv/linux.git (fixes)
by Linus Torvalds <torvalds@linux-foundation.org>:

On Thu, 12 Feb 2026 16:39:48 -0700 (MST) you wrote:
> Linus,
> 
> Please pull these RISC-V updates for v7.0.  The primary new feature
> here is support for CFI in user processes.  This feature has been
> tested by a set of RISC-V community participants, including by CPU
> IP/hardware vendors and by a major Linux distribution.  Other changes
> are described in the signed tag.
> 
> [...]

Here is the summary with links:
  - [GIT,PULL] RISC-V updates for v7.0
    https://git.kernel.org/riscv/c/cee73b1e840c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [GIT PULL] RISC-V updates for v7.0

[Peter Zijlstra]

On Wed, Feb 18, 2026 at 05:57:45PM -0800, Deepak Gupta wrote:

> x86 doesn't have any equivalent BTI bit in PTEs to mark code pages. IIRC, it
> does have mechanism where a bitmap has to be prepared and each entry in bitmap
> encodes whether a page is legacy code page (without `endbr64`) or a modern code
> page (with `endbr64`). And CPU will consult this bitmap to suppress the fault.

So; all of this is only ever relevant for programs that are mixing CFI
and !CFI code. If a program has no CFI, all good. If a program is all
CFI enabled, also all good.

If it starts mixing things, then you get to be 'creative'.

Now the thing is, if you start to do that you need to deal with both
forward CFI (BTI) and backward CFI (shadow-stack) #CF exceptions. That
bitmap, that can only deal with BTI, but doesn't help with shadow
stack, so its useless.

My proposal was to ignore that whole bitmap; that's dead hardware, never
used. Instead use a software PTE bit, like ARM has, and simply eat the
#CF look at PTE and figure out what to do.

Yes, this is 'slow', but my claim is that this doesn't matter. There are
2 ways out of this slow-ness:

 - fully disable CFI for your program (probably not the thing you want,
   but a quick fix, and not really less secure than partial CFI anyway).

 - fully enable CFI for your program (might be a bit of work).

The whole mixed thing is a transition state where userspace doesn't have
its ducks in a row. It will go away.

Re: [GIT PULL] RISC-V updates for v7.0

[Deepak Gupta]

Hi Peter,

Responses inline.

On Thu, Feb 26, 2026 at 02:23:42PM +0100, Peter Zijlstra wrote:
>On Wed, Feb 18, 2026 at 05:57:45PM -0800, Deepak Gupta wrote:
>
>> x86 doesn't have any equivalent BTI bit in PTEs to mark code pages. IIRC, it
>> does have mechanism where a bitmap has to be prepared and each entry in bitmap
>> encodes whether a page is legacy code page (without `endbr64`) or a modern code
>> page (with `endbr64`). And CPU will consult this bitmap to suppress the fault.
>
>So; all of this is only ever relevant for programs that are mixing CFI
>and !CFI code. If a program has no CFI, all good. If a program is all
>CFI enabled, also all good.
>
>If it starts mixing things, then you get to be 'creative'.
>
>Now the thing is, if you start to do that you need to deal with both
>forward CFI (BTI) and backward CFI (shadow-stack) #CF exceptions. That
>bitmap, that can only deal with BTI, but doesn't help with shadow
>stack, so its useless.
>
>My proposal was to ignore that whole bitmap; that's dead hardware, never
>used. Instead use a software PTE bit, like ARM has, and simply eat the
>#CF look at PTE and figure out what to do.

IIRC, arm has hardware PTE bit saying this is a guarded page. That can be kept
in ITLB as part of virt addr translation during instruction fetch. So whenever
indir_call --> target happens, if target translation was already in ITLB, CPU
already knows whether to suppress the fault or not, without going to kernel.

In x86 case, using a software PTE bit would be different. There will be a fault
always and kernel won't be able to make a decision on what to do. It'll need
some delegating authority to make that decision. That delegating authority can
be a signal handler in userspace which may need a bitmap/auxilliary data
structure of sort to make that decision whether target address is a taken target
or should not be taken.

So decision point is either

  - do a software bitmap or
  - hardware bitmap (legacy interworking bitmap)
    (both will be slow).

OR

  Just don't allow/support that configuration to enable CFI. And put onus on
  workload owner to do the work to enable the feature.

Sidenote: I wish we were able to convince someone certain in Redmond to give a
sw bit back and this all would have been nicer. Given there wasn't a lot of
traction from open source for this feature, it was mostly a redmond driven
feature.

>
>Yes, this is 'slow', but my claim is that this doesn't matter. There are
>2 ways out of this slow-ness:
>
> - fully disable CFI for your program (probably not the thing you want,
>   but a quick fix, and not really less secure than partial CFI anyway).
>
> - fully enable CFI for your program (might be a bit of work).
>
>The whole mixed thing is a transition state where userspace doesn't have
>its ducks in a row. It will go away.


I have spent 8 years defining features to kill class of low-level exploits back
at Intel. And then next 6 years in places where software is deployed on these
CPUs. 

I am a security engineer and would have loved to get these features enabled.
But in all honesty, I am yet to see anyone at these places (hyperscalars)
willing to give up an ounce of perf budget (1-2% demands discussion and strong
justification) for enabling just the shadow stack feature.

So my advise would be not to care about enabling path where there is a perf hit.

Keep it simple
- Enable when all binaries have feature awareness.
- Disable when there is one binary with no feature awareness.

>
>