linux-kernel - Re: [PATCH] x86/bugs: Don't warn when overwriting retbleed_return_thunk with srso_return

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250514233022.t72lijzi4ipgmmpj@desk>
Date: Wed, 14 May 2025 16:30:22 -0700
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Suraj Jitindar Singh <surajjs@...zon.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, stable@...r.kernel.org
Subject: Re: [PATCH] x86/bugs: Don't warn when overwriting
 retbleed_return_thunk with srso_return_thunk

On Thu, May 15, 2025 at 12:25:07AM +0200, Borislav Petkov wrote:
> On Wed, May 14, 2025 at 03:08:35PM -0700, Suraj Jitindar Singh wrote:
> > -	if (x86_return_thunk != __x86_return_thunk)
> > +	/*
> > +	 * There can only be one return thunk enabled at a time, so issue a
> > +	 * warning when overwriting it. retbleed_return_thunk is a special case
> > +	 * which is safe to be overwritten with srso_return_thunk since it
> > +	 * provides a superset of the functionality and is handled correctly in
> > +	 * entry_untrain_ret().
> > +	 */
> > +	if ((x86_return_thunk != __x86_return_thunk) &&
> > +	    (thunk != srso_return_thunk ||
> > +	     x86_return_thunk != retbleed_return_thunk))
> 
> Instead of making this an unreadable conditional, why don't we ...
> 
> >  		pr_warn("x86/bugs: return thunk changed\n");
> 
> ... turn this into a
> 
> 	pr_info("set return thunk to: %ps\n", ...)
> 
> and simply say which thunk was set?

This was discussed during the mitigation, and pr_warn() was chosen because
it was not obvious that srso mitigation also mitigates retbleed. (On a
retrospect, there should have been a comment about it).

The conclusion was to make the srso and retbleed relationship clear and
then take care of the pr_warn().