linux-kernel - [PATCH 00/15] KVM: X86: Fix and clean up for register caches

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: <20211108124407.12187-1-jiangshanlai@gmail.com>
Date:   Mon,  8 Nov 2021 20:43:52 +0800
From:   Lai Jiangshan <jiangshanlai@...il.com>
To:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     Lai Jiangshan <laijs@...ux.alibaba.com>
Subject: [PATCH 00/15] KVM: X86: Fix and clean up for register caches

From: Lai Jiangshan <laijs@...ux.alibaba.com>

The patchset was started when I read the code of nested_svm_load_cr3()
and found that it marks CR3 available other than dirty when changing
vcpu->arch.cr3.  I thought its caller has ensured that vmcs.GUEST_CR3
will be or already be set to @cr3 so that it doesn't need to be marked
dirty.  And later I found that it is not true and it must be a bug in
a rare case before I realized that all the code just (ab)uses
vcpu->arch.regs_avail for VCPU_EXREG_CR3 and there is not such bug
of using regs_avail here.
(The above finding becomes a low meaning patch_15 rather than a fix)

The unhappyness of the reading code made me do some cleanup for
regs_avail and regs_dirty and kvm_register_xxx() functions in the hope
that the code become clearer with less misunderstanding.

Major focus was on VCPU_EXREG_CR3 and VCPU_EXREG_PDPTR.  They are
ensured to be marked the correct tags (available or dirty), and the
value is ensured to be synced to architecture before run if it is marked
dirty.

When cleaning VCPU_EXREG_PDPTR, I also checked if the corresponding
cr0/cr4 pdptr bits are all intercepted when !tdp_enabled, and I think
it is not clear enough, so X86_CR4_PDPTR_BITS is added as self-comments
in the code.

Lai Jiangshan (15):
  KVM: X86: Ensure the dirty PDPTEs to be loaded
  KVM: VMX: Mark VCPU_EXREG_PDPTR available in ept_save_pdptrs()
  KVM: SVM: Always clear available of VCPU_EXREG_PDPTR in svm_vcpu_run()
  KVM: VMX: Add and use X86_CR4_TLB_BITS when !enable_ept
  KVM: VMX: Add and use X86_CR4_PDPTR_BITS when !enable_ept
  KVM: X86: Move CR0 pdptr_bits into header file as X86_CR0_PDPTR_BITS
  KVM: SVM: Remove outdate comment in svm_load_mmu_pgd()
  KVM: SVM: Remove useless check in svm_load_mmu_pgd()
  KVM: SVM: Remove the unneeded code to mark available for CR3
  KVM: X86: Mark CR3 dirty when vcpu->arch.cr3 is changed
  KVM: VMX: Update vmcs.GUEST_CR3 only when the guest CR3 is dirty
  KVM: VMX: Reset the bits that are meaningful to be reset in
    vmx_register_cache_reset()
  KVM: SVM: Add and use svm_register_cache_reset()
  KVM: X86: Remove kvm_register_clear_available()
  KVM: nVMX: Always write vmcs.GUEST_CR3 during nested VM-Exit

 arch/x86/kvm/kvm_cache_regs.h | 13 ++++++------
 arch/x86/kvm/svm/nested.c     |  1 -
 arch/x86/kvm/svm/svm.c        | 17 ++++++++--------
 arch/x86/kvm/svm/svm.h        | 26 ++++++++++++++++++++++++
 arch/x86/kvm/vmx/nested.c     | 30 ++++++++++++++++++----------
 arch/x86/kvm/vmx/vmx.c        | 12 +++++++-----
 arch/x86/kvm/vmx/vmx.h        | 37 +++++++++++++++++++++++++----------
 arch/x86/kvm/x86.c            | 13 ++++++------
 8 files changed, 101 insertions(+), 48 deletions(-)

-- 
2.19.1.6.gb485710b