On Tue, May 09, 2023 at 04:33:30PM +0300, ovidiu.panait@xxxxxxxxxxxxx wrote: > From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > commit 6cd88243c7e03845a450795e134b488fc2afb736 upstream. > > If a vCPU is outside guest mode and is scheduled out, it might be in the > process of making a memory access. A problem occurs if another vCPU uses > the PV TLB flush feature during the period when the vCPU is scheduled > out, and a virtual address has already been translated but has not yet > been accessed, because this is equivalent to using a stale TLB entry. > > To avoid this, only report a vCPU as preempted if sure that the guest > is at an instruction boundary. A rescheduling request will be delivered > to the host physical CPU as an external interrupt, so for simplicity > consider any vmexit *not* instruction boundary except for external > interrupts. > > It would in principle be okay to report the vCPU as preempted also > if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the > vmentry/vmexit overhead unnecessarily, and optimistic spinning is > also unlikely to succeed. However, leave it for later because right > now kvm_vcpu_check_block() is doing memory accesses. Even > though the TLB flush issue only applies to virtual memory address, > it's very much preferrable to be conservative. > > Reported-by: Jann Horn <jannh@xxxxxxxxxx> > Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > [OP: use VCPU_STAT() for debugfs entries] > Signed-off-by: Ovidiu Panait <ovidiu.panait@xxxxxxxxxxxxx> > --- > 5.10 backport of CVE-2022-39189 fix: > https://bugs.chromium.org/p/project-zero/issues/detail?id=2309 > Now queued up, thanks. greg k-h
