linux-kernel - Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of bug or mitigation status

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: <20230824220440.ltmozuypice2kmwg@treble>
Date:   Thu, 24 Aug 2023 15:04:40 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Andrew Cooper <andrew.cooper3@...rix.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Babu Moger <babu.moger@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>, David.Kaplan@....com,
        Nikolay Borisov <nik.borisov@...e.com>,
        gregkh@...uxfoundation.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 02/22] x86/srso: Set CPUID feature bits independently of
 bug or mitigation status

On Thu, Aug 24, 2023 at 06:24:20AM +0200, Borislav Petkov wrote:
> On Wed, Aug 23, 2023 at 01:22:34PM +0100, Andrew Cooper wrote:
> > In my previous reply, I explained why this goes wrong when Linux ignores
> > the CPUID bit provided by the hypervisor and decides to probe manually.
> 
> Send a patch and explain in its commit message *why* this is needed.
> 
> > No.
> 
> Hell yeah!
> 
> How do you expect us to support use cases we don't know about?!
> 
> > You don't get to take my code, break it when integrating it into Linux,
> > then dismiss the bug as something hypothetical that you don't want to fix.
> 
> I have no clue what you're talking about but it sounds like
> a misunderstanding. All I'm saying is, the live migration use cases the
> kernel should support, should be documented first. If there's no
> documentation for them, *then* you have hypothetical.
> 
> So patches explaining what we're supporting are welcome.

Something like this?

From: Josh Poimboeuf <jpoimboe@...nel.org>
Subject: [PATCH] x86/srso: Don't probe microcode in a guest

To support live migration, the hypervisor sets the "lowest common
denominator" of features.  Probing the microcode isn't allowed because
any detected features might go away after a migration.

As Andy Cooper states:

  "Linux must not probe microcode when virtualised.  What it may see
  instantaneously on boot (owing to MSR_PRED_CMD being fully passed
  through) is not accurate for the lifetime of the VM."

Rely on the hypervisor to set the needed IBPB_BRTYPE and SBPB bits.

Fixes: 1b5277c0ea0b ("x86/srso: Add SRSO_NO support")
Suggested-by: Andrew Cooper <andrew.cooper3@...rix.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@...nel.org>
---
 arch/x86/kernel/cpu/amd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index b08af929135d..28e77c5d6484 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -767,7 +767,7 @@ static void early_init_amd(struct cpuinfo_x86 *c)
 	if (cpu_has(c, X86_FEATURE_TOPOEXT))
 		smp_num_siblings = ((cpuid_ebx(0x8000001e) >> 8) & 0xff) + 1;
 
-	if (!cpu_has(c, X86_FEATURE_IBPB_BRTYPE)) {
+	if (!cpu_has(c, X86_FEATURE_HYPERVISOR) && !cpu_has(c, X86_FEATURE_IBPB_BRTYPE)) {
 		if (c->x86 == 0x17 && boot_cpu_has(X86_FEATURE_AMD_IBPB))
 			setup_force_cpu_cap(X86_FEATURE_IBPB_BRTYPE);
 		else if (c->x86 >= 0x19 && !wrmsrl_safe(MSR_IA32_PRED_CMD, PRED_CMD_SBPB)) {
-- 
2.41.0