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: <1c27be68-8365-4ddb-9368-e8e740feaf13@amazon.com>
Date: Tue, 1 Oct 2024 15:37:13 -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-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?

> 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?

Derek