[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250211164355.abxlbqhm3gym2e7b@jpoimboe>
Date: Tue, 11 Feb 2025 08:43:55 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: David Kaplan <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
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.
--
Josh
Powered by blists - more mailing lists