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-next>] [day] [month] [year] [list]
Message-ID: <20240802185511.305849-1-seanjc@google.com>
Date: Fri,  2 Aug 2024 11:55:02 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>, Sean Christopherson <seanjc@...gle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/9] KVM: x86: Add a quirk for feature MSR initialization

The primary goal of this series to fix an issue where KVM's initialization
of feature MSRs during vCPU creation results in a failed save/restore of
PERF_CAPABILITIES.  If userspace configures the VM to _not_ have a PMU,
because KVM initializes the vCPU's PERF_CAPABILTIIES, trying to save/restore
the non-zero value will be rejected by the destination.

The secondary goal is to try and avoid such goofs in the future, by making
it explicitly clear that userspace owns the vCPU model.

To achieve both goals, quirk KVM's initialization of feature MSRs and give
userspace full control of feature MSRs, mostly.  I left VMX_CR{0,4}_FIXED1
as-is, partly because there was pushback on quirking those in the past[1],
partly because I (somewhat begrudgingly) actually think that it makes sense
for KVM to take control of the allowed-1 CR4 bits, as there is no known use
case for having the post-VMXON CR4 bits diverge from pre-VMXON (guest CPUID),
and trying to sort out what should happen if there was a divergence would be
a mess.

I did apply the quirk to VMX secondary execution controls, because unlike
the CR{0,4} bits, KVM doesn't take _full_ control, and more importantly, I
want to stem the bleeding and avoid KVM fiddling with more VMX MSRs, e.g.
tertiary controls.

Note, this applies on top of the MSR userspace access series [2], and the
tests will fail without those underlying changes.

[1] https://lore.kernel.org/all/20220607213604.3346000-13-seanjc@google.com
[2] https://lore.kernel.org/all/20240802181935.292540-1-seanjc@google.com

Sean Christopherson (9):
  KVM: x86: Co-locate initialization of feature MSRs in
    kvm_arch_vcpu_create()
  KVM: x86: Disallow changing MSR_PLATFORM_INFO after vCPU has run
  KVM: x86: Quirk initialization of feature MSRs to KVM's max
    configuration
  KVM: x86: Reject userspace attempts to access PERF_CAPABILITIES w/o
    PDCM
  KVM: VMX: Remove restriction that PMU version > 0 for
    PERF_CAPABILITIES
  KVM: x86: Reject userspace attempts to access ARCH_CAPABILITIES w/o
    support
  KVM: x86: Remove ordering check b/w MSR_PLATFORM_INFO and
    MISC_FEATURES_ENABLES
  KVM: selftests: Verify get/set PERF_CAPABILITIES w/o guest PDMC
    behavior
  KVM: selftests: Add a testcase for disabling feature MSRs init quirk

 Documentation/virt/kvm/api.rst                |  22 ++++
 arch/x86/include/asm/kvm_host.h               |   3 +-
 arch/x86/include/uapi/asm/kvm.h               |   1 +
 arch/x86/kvm/svm/svm.c                        |   4 +-
 arch/x86/kvm/vmx/vmx.c                        |  11 +-
 arch/x86/kvm/x86.c                            |  34 +++---
 tools/testing/selftests/kvm/Makefile          |   2 +-
 .../selftests/kvm/x86_64/feature_msrs_test.c  | 113 ++++++++++++++++++
 .../kvm/x86_64/get_msr_index_features.c       |  35 ------
 .../selftests/kvm/x86_64/platform_info_test.c |   2 -
 .../selftests/kvm/x86_64/vmx_pmu_caps_test.c  |  23 ++++
 11 files changed, 189 insertions(+), 61 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/x86_64/feature_msrs_test.c
 delete mode 100644 tools/testing/selftests/kvm/x86_64/get_msr_index_features.c


base-commit: 540fa2dc3c53613817bd7b345e1466d4a6f0ab5d
-- 
2.46.0.rc2.264.g509ed76dc8-goog


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ