On Thu, Oct 10, 2024, Paolo Bonzini wrote: > On 10/9/24 19:49, Sean Christopherson wrote: > > Fix a (VMX only) bug reported by Maxim where KVM caches a stale SS.AR_BYTES > > when involuntary preemption schedules out a vCPU during vmx_vcpu_rest(), and > > ultimately clobbers the VMCS's SS.AR_BYTES if userspace does KVM_GET_SREGS > > => KVM_SET_SREGS, i.e. if userspace writes the stale value back into KVM. > > > > v4, as this is a spiritual successor to Maxim's earlier series. > > > > Patch 1 fixes the underlying problem by avoiding the cache in kvm_sched_out(). > > I think we want this one in stable? If anything, we should send Maxim's patch to stable trees. While not a complete fix, it resolves the only known scenario where caching SS.AR_BYTES is truly problematic, it's as low risk as patches get, and it's much more likely to backport cleanly to older kernels. > > Patch 2 fixes vmx_vcpu_reset() to invalidate the cache _after_ writing the > > VMCS, which also fixes the VMCS clobbering bug, but isn't as robust of a fix > > for KVM as a whole, e.g. any other flow that invalidates the cache too "early" > > would be susceptible to the bug, and on its own doesn't allow for the > > hardening in patch 3.
