linux-kernel - RE: [PATCH v3 19/35] Documentation/x86: Document the new attack vector controls

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:
 <LV3PR12MB92658C4F87BA9C4408457E2B94FD2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Tue, 11 Feb 2025 16:57:59 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>, Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Dave
 Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H .
 Peter Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 19/35] Documentation/x86: Document the new attack
 vector controls

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Josh Poimboeuf <jpoimboe@...nel.org>
> Sent: Tuesday, February 11, 2025 10:44 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter
> Zijlstra <peterz@...radead.org>; Pawan Gupta
> <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar <mingo@...hat.com>; Dave
> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v3 19/35] Documentation/x86: Document the new attack
> vector controls
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, Jan 08, 2025 at 02:24:59PM -0600, David Kaplan wrote:
> > +Cross-Thread
> > +^^^^^^^^^^^^
> > +
> > +The cross-thread attack vector involves a malicious userspace program
> > +or malicious VM either observing or attempting to influence the
> > +behavior of code running on the SMT sibling thread in order to exfiltrate data.
> > +
> > +Many cross-thread attacks can only be mitigated if SMT is disabled,
> > +which will result in reduced CPU core count and reduced performance.
> > +Enabling mitigations for the cross-thread attack vector may result in
> > +SMT being disabled, depending on the CPU vulnerabilities detected.
> > +
> > +*mitigate_cross_thread defaults to 'off'*
>
> How does STIBP fit into this?  It's a cross-thread mitigation, but it's much cheaper
> than, say, disabling SMT.
>
> The default is generally to enable STIBP where applicable, but *not* to disable SMT.
>

The current patch series treats STIBP and IBPB similar and will enable them if the user->user or guest->guest attack vectors are selected.

Technically STIBP is a cross-thread protection though and only needs to be enabled if cross-thread protection is desired.  The challenge here is that mitigate_cross_thread defaults to 'off', while STIBP has historically defaulted to 'on'.  This is arguably an inconsistency in the current code, although it presumably comes from the fact that enabling STIBP is relatively cheap while disabling SMT is not.  But from a security standpoint, only mitigating some attacks does not actually mitigate the attack vector.

Open to feedback on how to handle this.  I can leave it as is, and perhaps just document that STIBP gets enabled under the attack vectors mentioned above.  I do not want to change any of the mitigation defaults though.

Thanks --David Kaplan