From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEg5G-0004Nh-QH for qemu-devel@nongnu.org; Thu, 20 Sep 2012 08:42:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEg59-0000tP-V8 for qemu-devel@nongnu.org; Thu, 20 Sep 2012 08:42:22 -0400 Date: Thu, 20 Sep 2012 21:54:19 +1000 From: David Gibson Message-ID: <20120920115419.GK24695@truffula.fritz.box> References: <1348124922-24263-1-git-send-email-david@gibson.dropbear.id.au> <1348124922-24263-2-git-send-email-david@gibson.dropbear.id.au> <505AC84C.9060500@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <505AC84C.9060500@siemens.com> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/2] pseries: Synchronize qemu and KVM state on hypercalls List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-ppc@nongnu.org, qemu-stable@nongnu.org, qemu-devel@nongnu.org On Thu, Sep 20, 2012 at 09:39:56AM +0200, Jan Kiszka wrote: > On 2012-09-20 09:08, David Gibson wrote: > > Currently the KVM exit path for PAPR hypercalls does not synchronize the > > qemu cpu state with the KVM state. Mostly this works, because the actual > > hypercall arguments and return values are explicitly passed through the > > kvm_run structure. However, the hypercall path includes a privilege check, > > to ensure that only the guest kernel can invoke hypercalls, not the guest > > userspace. Because of the lack of sync, this privilege check will use an > > out of date copy of the MSR, which could lead either to guest userspace > > being able to invoke hypercalls (a security hole for the guest) or to the > > guest kernel being incorrectly refused privilege leading to various other > > failures. > > > > This patch fixes the bug by forcing a synchronization on the hypercall exit > > path. This does mean we have a potentially quite expensive get and set of > > the state, however performance critical hypercalls are generally already > > implemented inside KVM so this probably won't matter. If it is a > > performance problem we can optimize it later by having the kernel perform > > the privilege check. That will need a new capability, however, since qemu > > will still need the privilege check for older kernels. > > If it's just about reading a small subset of the state (a single MSR?) > to allow the privilege check, you can also open-code only that in HCALL > exit. If it really matters. We could, don't think it's worth the trouble. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson