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@xxxxxxxxxx> 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