Re: [PATCH v2 0/5] Usermode Indirect Branch Tracking

[Richard Patel <ripatel@wii.dev>]

On Sat, Jun 06, 2026 at 03:40:10PM +0200, Florian Weimer wrote:
> * Richard Patel:
> 
> > On Fri, Jun 05, 2026 at 09:34:46PM +0200, Florian Weimer wrote:
> >
> >> How do you detect that handling a signal is complete and IBT can be
> >> re-enabled?  Or is it re-enabled before entering the userspace signal
> >> handler?
> >
> > Hi Florian,
> >
> > In v1, we backed up the IBT CPU state into the (user-accessible) signal
> > frame from FRED/XSAVE, then restored it:
> > https://lore.kernel.org/lkml/20260517183024.16292-4-ripatel@wii.dev/
> >
> > In v2, when entering the signal handler, the kernel just context switches
> > to the new user rip, bypassing IBT checks (continues executing if the
> > signal handler does not begin with endbr).
> 
> What's the reason for this?

Hi Florian,

We just don't have a nice way to include IBT state in the signal frame
right now.  v1 had an uabi change (adding a new bit in ucontext_t uc_flags),
which was originally proposed by Intel years ago.  My preferred way to add
IBT state is to carve out an XSAVE area in fpstate, which works well with all
the existing signal frame code.

But I figured it's better to just keep the first pass at user IBT super
simple, in the hopes upstream is more inclined to accept that.

BTW, OpenBSD uses the v2 approach (don't preserve IBT state across signal
handlers), presumably because it's also hard for them to restore IBT state
on sigreturn.

> >> That's not necessarily a problem because its address cannot be directly
> >> overwritten in userspace.  Not all indirect branches need to be checked,
> >> only those that have tweakable targets.  In fact, fewer ENDBR64 markers
> >> are better (although we wouldn't drop the marker from a signal handler
> >> specifically, of course).
> >
> > Just one concern I have is that people start relying on signal handlers
> > not requiring endbr64, and then a future kernel version breaking them once
> > we enforce it.
> 
> Would software enforcement be a possibility?  The kernel could check if
> the landing pad is there.

Enforcement is the easy part.  I can trivially add back 'check if signal
handler starts with endbr64'.  Just the backup/restore of the pre-signal
handler state ('do I expect an endbr64 after returning') is the tricky part.

Thank you,
-Richard