diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-03-10 16:48:23 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-04-09 12:00:20 -0700 |
| commit | ba903f7382490776d2df2fca6bf5c8ef2eb4663f (patch) | |
| tree | e40135e08be48836eec50cd72feefd1695505da8 /scripts/stackusage | |
| parent | 2f34d421e8f041cf831b26a7596dc38336062d24 (diff) | |
KVM: SEV: Assert that kvm->lock is held when querying SEV+ support
Assert that kvm->lock is held when checking if a VM is an SEV+ VM, as KVM
sets *and* resets the relevant flags when initialization SEV state, i.e.
it's extremely easy to end up with TOCTOU bugs if kvm->lock isn't held.
Add waivers for a VM being torn down (refcount is '0') and for there being
a loaded vCPU, with comments for both explaining why they're safe.
Note, the "vCPU loaded" waiver is necessary to avoid splats on the SNP
checks in sev_gmem_prepare() and sev_gmem_max_mapping_level(), which are
currently called when handling nested page faults. Alternatively, those
checks could key off KVM_X86_SNP_VM, as kvm_arch.vm_type is stable early
in VM creation. Prioritize consistency, at least for now, and to leave a
"reminder" that the max mapping level code in particular likely needs
special attention if/when KVM supports dirty logging for SNP guests.
Link: https://patch.msgid.link/20260310234829.2608037-16-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions
