linux-kernel - Re: [patch V2 36/37] rseq: Switch to TIF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aLllFObsXWOtaVVI@google.com>
Date: Thu, 4 Sep 2025 03:08:20 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, Jens Axboe <axboe@...nel.dk>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Peter Zijlstra <peterz@...radead.org>, 
	"Paul E. McKenney" <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, Wei Liu <wei.liu@...nel.org>, 
	Dexuan Cui <decui@...rosoft.com>, x86@...nel.org, Arnd Bergmann <arnd@...db.de>, 
	Heiko Carstens <hca@...ux.ibm.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>, 
	Sven Schnelle <svens@...ux.ibm.com>, Huacai Chen <chenhuacai@...nel.org>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>
Subject: Re: [patch V2 36/37] rseq: Switch to TIF_RSEQ if supported

On Tue, Sep 02, 2025, Thomas Gleixner wrote:
> On Mon, Aug 25 2025 at 13:02, Sean Christopherson wrote:
> > On Sat, Aug 23, 2025, Thomas Gleixner wrote:
> >> @@ -122,7 +122,7 @@ static inline void rseq_force_update(voi
> >>   */
> >>  static inline void rseq_virt_userspace_exit(void)
> >>  {
> >> -	if (current->rseq_event.sched_switch)
> >> +	if (!IS_ENABLED(CONFIG_HAVE_GENERIC_TIF_BITS) && current->rseq_event.sched_switch)
> >
> > Rather than pivot on CONFIG_HAVE_GENERIC_TIF_BITS, which makes the "why" quite
> > difficult to find/understand, what if this checks TIF_RSEQ == TIF_NOTIFY_RESUME?
> > That would also allow architectures to define TIF_RSEQ without switching to the
> > generic TIF bits implementation (though I don't know that we want to encourage
> > that?).
> 
> Did you read the cover letter?

I read part of it :-)

> Consolidating on common infrastructure is the goal here. Stop
> proliferating the architecture specific hackery, which has zero value
> and justification. If people want to harvest the core improvements, then
> they should get their act together and mop up their architecture
> code. If they can't be bothered, so be it.

Definitely no argument on that front.

> I'm happy to add a comment which explains that.

And maybe a BUILD_BUG_ON() to assert that TIF_RSEQ != TIF_NOTIFY_RESUME?  My main
interest is documenting why the generic implementation doesn't need to re-raise
TIF_NOTIFY_RESUME.  E.g. something like this?

/*
 * KVM/HYPERV invoke resume_user_mode_work() before entering guest mode,
 * which clears TIF_NOTIFY_RESUME on architectures that don't provide support
 * the generic TIF bits.  To avoid updating user space RSEQ in that case just
 * to do it eventually again before returning to user space,
 * __rseq_handle_slowpath() does nothing when invoked with NULL register state.
 *
 * After returning from guest mode, before exiting to userspace, hypervisors
 * must invoke this function to re-raise TIF_NOTIFY_RESUME if necessary.
 */
static inline void rseq_virt_userspace_exit(void)
{
	/*
	 * The generic optimization for deferring RSEQ updates until the next
	 * exit relies on having a dedicated TIF_RSEQ.
	 */
	if (IS_ENABLED(CONFIG_HAVE_GENERIC_TIF_BITS))
		BUILD_BUG_ON(TIF_RSEQ == TIF_NOTIFY_RESUME);
	else if (current->rseq_event.sched_switch)
		rseq_raise_notify_resume(current);
}