linux-kernel - [PATCH 00/10] VM: SVM: Honor KVM_MAX

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: <20230815213533.548732-1-seanjc@google.com>
Date:   Tue, 15 Aug 2023 14:35:23 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Joerg Roedel <joro@...tes.org>
Cc:     kvm@...r.kernel.org, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org, Maxim Levitsky <mlevitsk@...hat.com>
Subject: [PATCH 00/10] VM: SVM: Honor KVM_MAX_VCPUS when AVIC is enabled

The only true functional change in this entire mess is to change KVM's
handling of KVM_CREATE_VCPU when AVIC is enabled.  Currently, KVM rejects
vCPU creation if the vcpu_id is unaddressable, i.e. if it's larger than
what is suppported by AVIC/x2AVIC hardware.  That is a rather blatant
violation of both KVM_CAP_MAX_VCPUS and KVM_CAP_MAX_VCPU_ID, as KVM will
advertise a KVM_CAP_MAX_VCPUS as 1024 and KVM_CAP_MAX_VCPU_ID as 4096,
but then reject vcpu_ids as low as 256 (AVIC).

To fix the problem, add yet another AVIC inhibit to disable AVIC if
userspace creates unaddressable vCPUs.  Alternatively, KVM could report
different KVM_CAP_MAX_VCPUS and KVM_CAP_MAX_VCPU_ID values when AVIC is
enabled, but IMO that path sets KVM up for failure, e.g. it would make it
really hard for us to enable AVIC/x2AVIC by default, and we'd have to have
to rework KVM selftests, which assume that KVM supports at least 512 vCPUs,
e.g. recalc_apic_map_test fails when AVIC is enabled.

The bulk of this series is cleaning up related code, most of which is
purely opportunistic, e.g. the many pointless PA masks, but some of which
are functionally "necessary", for some definitions of necessary.

Lightly tested, and the IOMMU interaction is basically compile tested only.
But this is firmly post-6.6 material, so no rush on anyone testing this
(I wouldn't even care all that much if the darn selftests didn't fail).

Sean Christopherson (10):
  KVM: SVM: Drop pointless masking of default APIC base when setting
    V_APIC_BAR
  KVM: SVM: Use AVIC_HPA_MASK when initializing vCPU's Physical ID entry
  KVM: SVM: Drop pointless masking of kernel page pa's with "AVIC's" HPA
    mask
  KVM: SVM: Add helper to deduplicate code for getting AVIC backing page
  KVM: SVM: Drop vcpu_svm's pointless avic_backing_page field
  iommu/amd: KVM: SVM: Use pi_desc_addr to derive ga_root_ptr
  KVM: SVM: Inhibit AVIC if ID is too big instead of rejecting vCPU
    creation
  KVM: SVM: WARN if KVM attempts to create AVIC backing page with user
    APIC
  KVM: SVM: Drop redundant check in AVIC code on ID during vCPU creation
  KVM: SVM: Rename "avic_physical_id_cache" to "avic_physical_id_entry"

 arch/x86/include/asm/kvm_host.h |  6 +++
 arch/x86/include/asm/svm.h      |  6 +--
 arch/x86/kvm/svm/avic.c         | 79 +++++++++++++++------------------
 arch/x86/kvm/svm/svm.h          |  6 +--
 drivers/iommu/amd/iommu.c       |  2 +-
 include/linux/amd-iommu.h       |  1 -
 6 files changed, 48 insertions(+), 52 deletions(-)

base-commit: 240f736891887939571854bd6d734b6c9291f22e
-- 
2.41.0.694.ge786442a9b-goog