[lkml]   [2021]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: There is a null-ptr-deref bug in kvm_dirty_ring_get in virt/kvm/dirty_ring.c
On Thu, 2021-10-21 at 22:08 +0200, Paolo Bonzini wrote:
> On 18/10/21 19:14, butt3rflyh4ck wrote:
> > {
> > struct kvm_vcpu *vcpu = kvm_get_running_vcpu(); //-------> invoke
> > kvm_get_running_vcpu() to get a vcpu.
> >
> > WARN_ON_ONCE(vcpu->kvm != kvm); [1]
> >
> > return &vcpu->dirty_ring;
> > }
> > ```
> > but we had not called KVM_CREATE_VCPU ioctl to create a kvm_vcpu so
> > vcpu is NULL.
> It's not just because there was no call to KVM_CREATE_VCPU; in general
> kvm->dirty_ring_size only works if all writes are associated to a
> specific vCPU, which is not the case for the one of
> kvm_xen_shared_info_init.
> David, what do you think? Making dirty-page ring buffer incompatible
> with Xen is ugly and I'd rather avoid it; taking the mutex for vcpu 0 is
> not an option because, as the reporter said, you might not have even
> created a vCPU yet when you call KVM_XEN_HVM_SET_ATTR. The remaining
> option would be just "do not mark the page as dirty if the ring buffer
> is active". This is feasible because userspace itself has passed the
> shared info gfn; but again, it's ugly...

I think I am coming to quite like that 'remaining option' as long as we
rephrase it as follows:

KVM does not mark the shared_info page as dirty, and userspace is
expected to *assume* that it is dirty at all times. It's used for
delivering event channel interrupts and the overhead of marking it
dirty each time is just pointless.

I've merged the patch I sent yesterday into my pfncache series because
I realised we needed the same there, but I'll look at making the Xen
code *not* mark the shinfo page dirty when it writes the clock data

Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.

 \ /
  Last update: 2021-11-17 10:47    [W:0.321 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site