[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2f556fa-8562-f2d3-37a0-220af33732cd@redhat.com>
Date: Tue, 21 Jan 2020 17:14:02 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <sean.j.christopherson@...el.com>,
Peter Xu <peterx@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Christophe de Dinechin <dinechin@...hat.com>,
"Michael S . Tsirkin" <mst@...hat.com>,
Yan Zhao <yan.y.zhao@...el.com>,
Alex Williamson <alex.williamson@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Kevin Kevin <kevin.tian@...el.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
"Dr . David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [PATCH v3 09/21] KVM: X86: Don't track dirty for
KVM_SET_[TSS_ADDR|IDENTITY_MAP_ADDR]
On 21/01/20 16:56, Sean Christopherson wrote:
> This code also needs to be tested by doing unrestricted_guest=0 when
> loading kvm_intel, because it's obviously broken.
... as I had just found out after starting tests on kvm/queue. Unqueued
this patch.
Paolo
> __x86_set_memory_region()
> takes an "unsigned long *", interpreted as a "pointer to a usersepace
> address", i.e. a "void __user **". But the callers are treating the param
> as a "unsigned long in userpace", e.g. init_rmode_identity_map() declares
> uaddr as an "unsigned long *", when really it should be declaring a
> straight "unsigned long" and passing "&uaddr". The only thing that saves
> KVM from dereferencing a bad pointer in __x86_set_memory_region() is that
> uaddr is initialized to NULL
Powered by blists - more mailing lists