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

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

Message-ID: <f4068cdc-2522-4730-b42d-991e886110ba@amazon.com>
Date: Wed, 2 Oct 2024 13:11:45 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <david.kaplan@....com>
CC: <bp@...en8.de>, <dave.hansen@...ux.intel.com>, <derekmn@...zon.com>,
	<hpa@...or.com>, <jpoimboe@...nel.org>, <linux-kernel@...r.kernel.org>,
	<mingo@...hat.com>, <pawan.kumar.gupta@...ux.intel.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 14:28+0000 David Kaplan wrote:
> On 2024-10-01 22:37+0000 Derek Manwaring 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?
>
> Hmm, I'm not quite sure how to do that because mitigate_user_user
> defaults to 'on' (again, to maintain the existing kernel defaults).  It
> seems odd to me that explicitly specifying 'mitigate_user_user=on' would
> result in different behavior.  And I think many vulnerabilities that
> require SMT disabled will already print out a warning if mitigation is
> requested and SMT is enabled.  Open to ideas here...

Yeah this would be awkward. Maybe the warning is enough. It just makes
SMT such an exception.

> > > In theory, cross-thread protection is only required if there is a risk
> > > that untrusted workloads might run as siblings.  If techniques like
> > > core scheduling are used, this might be able to be prevented I suppose.
> >
> > True, though I think it's worth making clear that doing core scheduling correctly is
> > the user's responsibility, and the vector protection they asked for may be incomplete
> > if there are mistakes in how they manage process cookies. Just an idea, but what if
> > users had to ask for SMT to remain enabled if they had also asked for protection
> > from one of these vectors?
>
> I think the fact that some mitigations will print warnings if SMT is
> enabled might be sufficient here.  I can also add something more about
> core scheduling in the documentation file.

That works. Personally I would say make the SMT and core scheduling bits
clear in the documentation and remove mitigate_cross_threads since it's
not inherently two separate domains like the others are
(user/kernel/guest/host).

It should be clear that SMT is the one case where specifying a vector
will not necessarily give you sufficient protection (unless we can find
an intuitive/low-surprise way to disable SMT when required to mitigate
certain vulnerabilities for the configured vector on affected parts).

Derek