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)