[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241002155049.zblyafe4zmnghqtw@desk>
Date: Wed, 2 Oct 2024 08:50:49 -0700
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: "Manwaring, Derek" <derekmn@...zon.com>
Cc: david.kaplan@....com, bp@...en8.de, dave.hansen@...ux.intel.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 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.
Powered by blists - more mailing lists