linux-kernel - Re: [RFC PATCH 21/34] x86/bugs: Add attack vector controls for mds

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: <f5398702-18d1-4b1e-80ee-d1643c59b643@amazon.com>
Date: Wed, 2 Oct 2024 12:40:13 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <pawan.kumar.gupta@...ux.intel.com>
CC: <bp@...en8.de>, <dave.hansen@...ux.intel.com>, <david.kaplan@....com>,
	<derekmn@...zon.com>, <hpa@...or.com>, <jpoimboe@...nel.org>,
	<linux-kernel@...r.kernel.org>, <mingo@...hat.com>, <peterz@...radead.org>,
	<tglx@...utronix.de>, <x86@...nel.org>
Subject: Re: [RFC PATCH 21/34] x86/bugs: Add attack vector controls for mds

On 2024-10-02  08:50-0700 Pawan Gupta wrote:
> On Tue, Oct 01, 2024 at 03:37:13PM -0700, Manwaring, Derek wrote:
> > On 2024-10-01 01:56+0000 David Kaplan wrote:
> > > On 2024-09-30 17:50-0700 Derek Manwaring wrote:
> > > > Maybe I'm missing something here - if you care about user/user, why would
> > > > you not care about cross-thread? It seems to me SMT should be turned off
> > > > for all of the vectors.
> > >
> > > I broke out cross-thread separately to maintain the existing kernel
> > > defaults, which does not disable SMT by default even if full mitigation
> > > requires it.
> >
> > Ok that makes a lot of sense. My bias would be to use the vector
> > parameters as an opportunity to make the SMT stance more obvious. So
> > kernel's position becomes more of "I disabled SMT because you asked for
> > protection with mitigate_user_user" (or any other vector). If no vector
> > parameters are specified, SMT default would be maintained. What are your
> > thoughts on disabling SMT if a vector parameter is explicitly supplied?
>
> I think attack vector mitigation like user-user does not necessarily mean
> SMT needs to be disabled. For example, for a system only affected by
> Spectre-v2, selecting user-user mitigation should deploy STIBP and IBPB,
> rather than disabling SMT.
>
> IMO, unless explicitly asked by a user, the decision to disable SMT should
> be left to individual mitigations.

Maybe so. Agree on preferring targeted mitigations rather than
disabling SMT where possible.

Derek