linux-kernel - Re: [PATCH 0/4] KVM: nSVM: nested VMSAVE/VMLOAD fixes

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] [day] [month] [year] [list]

Message-ID: <176849539790.691793.6615872461180369815.b4-ty@google.com>
Date: Thu, 15 Jan 2026 10:03:38 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>, Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Jim Mattson <jmattson@...gle.com>, 
	Kevin Cheng <chengkev@...gle.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] KVM: nSVM: nested VMSAVE/VMLOAD fixes

On Sat, 10 Jan 2026 00:48:17 +0000, Yosry Ahmed wrote:
> A couple of fixes for nested VMLOAD/VMSAVE and a selftest that verifies
> correct behavior. The test fails without patch 1.
> 
> Patch 4 is a proposed added WARNING, I am not sure if such warnings are
> generally acceptable and if that's the correct place for it (hence RFC),
> but I think it's useful to WARN if VMSAVE/VMLOAD are neither intercepted
> nor virtualized by the CPU, because it means that the guest is directly
> accessing host memory with them, a massive security hole.

Sanity checks in KVM are definitely acceptable/encourage, but this particular
check goes too far.  There are sooooo many things that KVM _must_ get right;
asserting on every single one without strong evidence that we're likely to
screw up without noticing isn't something I want to encourage.

In other words, for me, "the consequences are really bad" isn't sufficient
justification on its own, there also needs to be some amount of "we've botched
this multiple times in the past", "it's tricky to get right", and/or "this is a
low level API that makes assumptions about how the rest of KVM works".

> [...]

Applied 1-2 to kvm-x86 svm, and 3 to kvm-x86 selftests due to its dependency
on the selftests NPT support.  Note, this means running the selftests branch
without the fixes from the svm branch will fail.  Far from ideal, but IMO it's
not worth doing a merge for something that is unlikely to ever be a problem in
practice (and now I've jinxed myself).

[1/4] KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation
      https://github.com/kvm-x86/linux/commit/127ccae2c185
[2/4] KVM: SVM: Stop toggling virtual VMSAVE/VMLOAD on intercept recalc
      https://github.com/kvm-x86/linux/commit/55780d8a1dcc
[3/4] KVM: selftests: Add a selftests for nested VMLOAD/VMSAVE
      https://github.com/kvm-x86/linux/commit/55058e32151f
[4/4] RFC: KVM: SVM: WARN if VMSAVE/VMLOAD are not intercepted or virtualized
      [DROPPED]

--
https://github.com/kvm-x86/linux/tree/next