From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH V4 7/7] KVM, pkeys: disable PKU feature without ept Date: Wed, 9 Mar 2016 15:50:46 +0800 Message-ID: <56DFD5D6.3030104@linux.intel.com> References: <1457177252-7577-1-git-send-email-huaitong.han@intel.com> <1457177252-7577-8-git-send-email-huaitong.han@intel.com> <56DBF834.1020309@linux.intel.com> <56DC93D1.2070204@redhat.com> <56DE6919.4060107@linux.intel.com> <56DE91BD.4010502@redhat.com> <56DE9C45.4090504@linux.intel.com> <56DEA33B.1010005@redhat.com> <56DFB9E4.1050609@linux.intel.com> <56DFC4BE.8080406@gmail.com> <56DFCEE2.3030101@linux.intel.com> <56DFD3AE.8070509@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Yang Zhang , Paolo Bonzini , Huaitong Han , gleb@kernel.org Return-path: Received: from mga01.intel.com ([192.55.52.88]:15968 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbcCIHvM (ORCPT ); Wed, 9 Mar 2016 02:51:12 -0500 In-Reply-To: <56DFD3AE.8070509@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/09/2016 03:41 PM, Yang Zhang wrote: > On 2016/3/9 15:21, Xiao Guangrong wrote: >> >> >> On 03/09/2016 02:37 PM, Yang Zhang wrote: >>> On 2016/3/9 13:51, Xiao Guangrong wrote: >>>> >>>> >>>> On 03/08/2016 06:02 PM, Paolo Bonzini wrote: >>>>> >>>>> >>>>> On 08/03/2016 10:32, Xiao Guangrong wrote: >>>>>> On 03/08/2016 04:47 PM, Paolo Bonzini wrote: >>>>>>> Some XSAVE features (currently only MPX, but in the future PKRU= too) >>>>>>> will force eagerfpu on, see fpu__init_system_ctx_switch: >>>>>>> >>>>>>> if (xfeatures_mask & XFEATURE_MASK_EAGER) { >>>>>>> if (eagerfpu =3D=3D DISABLE) { >>>>>>> xfeatures_mask &=3D ~XFEATURE_MASK_EA= GER; >>>>>> >>>>>> So if the kernel parameter, eagerfpu is set to "off", then eager= is >>>>>> not >>>>>> enabled, so PKRU can not work in KVM? >>>>> >>>>> Yes. Neither PKRU nor MPX. >>>> >>>> Er... I noticed fpregs is not switched if the CPU is running in KV= M >>>> module >>>> (vcpu is not scheduled out and does not exit to userspace), that i= s why >>>> read_pkru() can be used to read guest's PKRU in the patch 4. >>>> >>>> However, then guest can fully control the access of userspace's >>>> memory if >>>> CR4.PKRU is enabled on host and KVM needs to access QEMU's memory = to do >>>> some >>>> emulation anyway. Is it really safe=EF=BC=9F >>> >>> I think it depends on how we understand the guest uses Pkeys. From = my >>> point, guest only wants to >>> protect the pages from guest's view, not kvm. So the access from KV= M >>> should be totally transparent >>> to guest. And should not be aware by guest. For modification, i thi= nk >>> current KVM only touch the DMA >>> buffer which is setup by guest driver. It's guest responsibility to >>> ensure the pages he want to >>> protect are not used as DMA buffer. >>> >> >> No really. A example is KVM need to read guest memory to emulate som= e >> instructions. > > This is the access case. I don't think guest is interesting in such a= ccess. See below. > >> >> More worse, the pkey-bits on pte entry is different between guest an= d >> host (they >> are using different page tables) so guest can not know what index in >> PKRU will be >> used by KVM. A evil guest can use it to attack host... > > Can you give a example how a evil guest can attack host? > > One question is if host and guest are both using pkeys, how to handle= this case? I don't see current > patch consider this case? This is exact what i said... Currently, this patchset did not recover host's PKRU then host will use guest's PKRU to do memory access.