linux-kernel - Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR

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: <20250108154901.GFZ36ebXAZMFZJ7D8t@fat_crate.local>
Date: Wed, 8 Jan 2025 16:49:01 +0100
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Borislav Petkov <bp@...nel.org>, X86 ML <x86@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	KVM <kvm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR_FIX

On Wed, Jan 08, 2025 at 05:38:39AM -0800, Sean Christopherson wrote:
> The "host" value will only be restored when the CPU exits to userspace, so if
> there are no userspace tasks running on those CPUs, i.e. nothing that forces them
> back to userspace, then it's expected for them to have the "guest" value loaded,
> even after the guest is long gone.  Unloading KVM effectively forces KVM to simulate
> a return to userspace and thus restore the host values.

Aha, makes sense.

> Hmm, mostly out of curiosity, what's the "workload"?

Oh, very very exciting: booting a guest! :-P

> And do you know what 0xd23f corresponds to?

How's that:

$ objdump -D arch/x86/kvm/kvm.ko
...
000000000000d1a0 <kvm_vcpu_halt>:
    d1a0:       e8 00 00 00 00          call   d1a5 <kvm_vcpu_halt+0x5>
    d1a5:       55                      push   %rbp
    ...

    d232:       e8 09 93 ff ff          call   6540 <kvm_vcpu_check_block>
    d237:       85 c0                   test   %eax,%eax
    d239:       0f 88 f6 01 00 00       js     d435 <kvm_vcpu_halt+0x295>
    d23f:       f3 90                   pause
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    d241:       e8 00 00 00 00          call   d246 <kvm_vcpu_halt+0xa6>
    d246:       48 89 c3                mov    %rax,%rbx
    d249:       e8 00 00 00 00          call   d24e <kvm_vcpu_halt+0xae>
    d24e:       84 c0                   test   %al,%al


Which makes sense :-)

> Yeah, especially if this is all an improvement over the existing mitigation.
> Though since it can impact non-virtualization workloads, maybe it should be a
> separately selectable mitigation?  I.e. not piggybacked on top of ibpb-vmexit?

Well, ibpb-on-vmexit is your typical cloud provider scenario where you address
the VM/VM attack vector by doing an IBPB on VMEXIT. This SRSO_MSR_FIX thing
protects the *host* from a malicious guest so you need both enabled for full
protection on the guest/host vector.

 (And yeah, I'm talking about attack vectors because this way of thinking about
  the mitigations will simplify stuff a lot:

  https://lore.kernel.org/r/20241105215455.359471-1-david.kaplan@amd.com
  )

Ok, lemme send a proper patch...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette