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 16:05:51 +0800 Message-ID: <56DFD95F.1010108@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> <56DFD5D6.3030104@linux.intel.com> <56DFD826.6000308@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]:51108 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbcCIIGW (ORCPT ); Wed, 9 Mar 2016 03:06:22 -0500 In-Reply-To: <56DFD826.6000308@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/09/2016 04:00 PM, Yang Zhang wrote: > On 2016/3/9 15:50, Xiao Guangrong wrote: >> >> >> 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 PK= RU >>>>>>>>> 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_= EAGER; >>>>>>>> >>>>>>>> So if the kernel parameter, eagerfpu is set to "off", then eag= er 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 = KVM >>>>>> module >>>>>> (vcpu is not scheduled out and does not exit to userspace), that= is >>>>>> 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 memor= y >>>>>> to do >>>>>> some >>>>>> emulation anyway. Is it really safe=EF=BC=9F >>>>> >>>>> I think it depends on how we understand the guest uses Pkeys. Fro= m my >>>>> point, guest only wants to >>>>> protect the pages from guest's view, not kvm. So the access from = KVM >>>>> should be totally transparent >>>>> to guest. And should not be aware by guest. For modification, i t= hink >>>>> 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 s= ome >>>> instructions. >>> >>> This is the access case. I don't think guest is interesting in such >>> access. >> >> See below. >> >>> >>>> >>>> More worse, the pkey-bits on pte entry is different between guest = and >>>> 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 hand= le >>> this case? I don't see current >>> patch consider this case? >> >> This is exact what i said... > > Ah...I thought you are asking whether we should let guest aware the a= ccess from hypervisor. Sorry to > misread your mail. > >> >> Currently, this patchset did not recover host's PKRU then host will = use >> guest's PKRU to do memory access. > > This definitely wrong. Besides, should we consider host's setting whe= n guest is running? We should. No reason stop QEMU and other KVM-based hypervisors using pr= otection-key. :)