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.