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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

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.