linux-kernel - [PATCH v2 0/4] Introduce a quirk to control memslot zap behavior

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: <20240703020921.13855-1-yan.y.zhao@intel.com>
Date: Wed,  3 Jul 2024 10:09:20 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: pbonzini@...hat.com,
	seanjc@...gle.com
Cc: rick.p.edgecombe@...el.com,
	kai.huang@...el.com,
	isaku.yamahata@...el.com,
	dmatlack@...gle.com,
	sagis@...gle.com,
	erdemaktas@...gle.com,
	graf@...zon.com,
	linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org,
	Yan Zhao <yan.y.zhao@...el.com>
Subject: [PATCH v2 0/4] Introduce a quirk to control memslot zap behavior

Today "zapping only leaf SPTEs with memslot range" ("zap-slot-leafs-only"
for short) on moving/deleting a memslot is not done. Instead, KVM opts to
invalidate all page tables and generate fresh new ones based on the new
memslot layout ("zap-all" for short). This "zap-all" behavior is of low
overhead for most use cases, and is adopted primarily due to a bug which
caused VM instability when a VM is with Nvidia Geforce GPU assigned (see
link in patch 1).

However, the "zap-all" behavior is not desired for certain specific
scenarios. e.g.
- It's not viable for TDX,
  a) TDX requires root page of private page table remains unaltered
     throughout the TD life cycle.
  b) TDX mandates that leaf entries in private page table must be zapped
     prior to non-leaf entries.
  c) TDX requires re-accepting of private pages after page dropping.
- It's not performant for scenarios involving frequent deletion and
  re-adding of numerous small memslots.

This series therefore introduces the KVM_X86_QUIRK_SLOT_ZAP_ALL quirk,
enabling users to control the behavior of memslot zapping when a memslot is
moved/deleted for VMs of type KVM_X86_DEFAULT_VM.

The quirk is turned on by default for VMs of type KVM_X86_DEFAULT_VM,
leading to "zap-all" behavior.

Users have the option to turn off the quirk. Doing so will have KVM go
"zap-slot-leafs-only" on memslot moving/deleting.

KVM will always select "zap-slot-leafs-only" as if the quirk is disabled
for non-KVM_X86_DEFAULT_VM VMs for reasons explained in patch 1.

This series has been tested with
- Normal VMs
  w/ and w/o device assignment, and kvm selftests

- TDX guests.
  Tested with shared device assignment and guest memory hot-plug/unplug.

It can be applied to both kvm/queue and kvm-coco-queue.

Patch 1:   KVM changes.
Patch 2-4: Selftests updates. Verify memslot move/deletion functionality
           with the quirk enabled/disabled.

Changelog:
v1 --> v2:
- Make KVM behave as if the quirk is always disabled on
  non-KVM_X86_DEFAULT_VM VMs. (Sean, Rick)
- Removed the patch for selftest private_mem_kvm_exits_test, since that
  selftest is for VM type KVM_X86_SW_PROTECTED_VM.

v1: https://lore.kernel.org/all/20240613060708.11761-1-yan.y.zhao@intel.com

Yan Zhao (4):
  KVM: x86/mmu: Introduce a quirk to control memslot zap behavior
  KVM: selftests: Test slot move/delete with slot zap quirk
    enabled/disabled
  KVM: selftests: Allow slot modification stress test with quirk
    disabled
  KVM: selftests: Test memslot move in memslot_perf_test with quirk
    disabled

 Documentation/virt/kvm/api.rst                |  8 ++++
 arch/x86/include/asm/kvm_host.h               |  3 +-
 arch/x86/include/uapi/asm/kvm.h               |  1 +
 arch/x86/kvm/mmu/mmu.c                        | 42 ++++++++++++++++++-
 .../kvm/memslot_modification_stress_test.c    | 19 ++++++++-
 .../testing/selftests/kvm/memslot_perf_test.c | 12 +++++-
 .../selftests/kvm/set_memory_region_test.c    | 29 +++++++++----
 7 files changed, 101 insertions(+), 13 deletions(-)

-- 
2.43.2