linux-kernel - RE: [PATCH 2/2] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <LV3PR12MB926587E1175B9450C34C17829493A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Fri, 16 May 2025 15:18:30 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>, Suraj Jitindar Singh <surajjs@...zon.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar
	<mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH 2/2] x86/bugs: Don't WARN() when overwriting
 retbleed_return_thunk with srso_return_thunk

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Friday, May 16, 2025 2:48 AM
> To: Suraj Jitindar Singh <surajjs@...zon.com>; Kaplan, David
> <David.Kaplan@....com>
> Cc: linux-kernel@...r.kernel.org; x86@...nel.org; Thomas Gleixner
> <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>; Josh Poimboeuf
> <jpoimboe@...nel.org>; Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>;
> Ingo Molnar <mingo@...hat.com>; Dave Hansen
> <dave.hansen@...ux.intel.com>; stable@...r.kernel.org
> Subject: Re: [PATCH 2/2] x86/bugs: Don't WARN() when overwriting
> retbleed_return_thunk with srso_return_thunk
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, May 15, 2025 at 04:34:33PM -0700, Suraj Jitindar Singh wrote:
> > -     WARN(x86_return_thunk != __x86_return_thunk,
> > +     WARN((x86_return_thunk != __x86_return_thunk) &&
> > +          (thunk != srso_return_thunk ||
> > +           x86_return_thunk != retbleed_return_thunk),
> >            "x86/bugs: return thunk changed from %ps to %ps\n",
> >            x86_return_thunk, thunk);
>
> This is still adding that nasty conditional which I'd like to avoid.
>
> And I just had this other idea: we're switching to select/update/apply logic with the
> mitigations and I'm sure we can use that new ability to select the proper mitigation
> when other mitigations are influencing the decision, to select the proper return
> thunk.
>
> I'm thinking for retbleed and SRSO we could set it only once, perhaps in
> srso_select_mitigation() as it runs last.
>
> I don't want to introduce an amd_return_thunk... :-)
>
> But David might have a better idea...
>

Hmm.  Since SRSO is kind of a superset of retbleed, it might make sense to create a new mitigation, RETBLEED_MITIGATION_SAFE_RET.

retbleed_update_mitigation() can change its mitigation to this if srso_mitigation is SAFE_RET (or SAFE_RET_UCODE_NEEDED).  RETBLEED_MITIGATION_SAFE_RET can do nothing in retbleed_apply_mitigation() because it means that srso is taking care of things.  Thoughts?

This also made me realize there's another minor missing interaction here, which is that if spec_rstack_overflow=ibpb, then that should set retbleed_mitigation to IBPB as well.

--David Kaplan