From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Zhang Subject: Re: [PATCH V4 7/7] KVM, pkeys: disable PKU feature without ept Date: Wed, 9 Mar 2016 16:00:38 +0800 Message-ID: <56DFD826.6000308@gmail.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Xiao Guangrong , Paolo Bonzini , Huaitong Han , gleb@kernel.org Return-path: Received: from mail-pa0-f68.google.com ([209.85.220.68]:33789 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752425AbcCIIAr (ORCPT ); Wed, 9 Mar 2016 03:00:47 -0500 Received: by mail-pa0-f68.google.com with SMTP id q6so2748647pav.0 for ; Wed, 09 Mar 2016 00:00:47 -0800 (PST) In-Reply-To: <56DFD5D6.3030104@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 PKR= U >>>>>>>> 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_E= AGER; >>>>>>> >>>>>>> So if the kernel parameter, eagerfpu is set to "off", then eage= r 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 K= VM >>>>> 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 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 K= VM >>>> should be totally transparent >>>> to guest. And should not be aware by guest. For modification, i th= ink >>>> current KVM only touch the DMA >>>> buffer which is setup by guest driver. It's guest responsibility t= o >>>> 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 so= me >>> 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 a= nd >>> host (they >>> are using different page tables) so guest can not know what index i= n >>> 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 handl= e >> 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=20 access from hypervisor. Sorry to misread your mail. > > Currently, this patchset did not recover host's PKRU then host will u= se > guest's PKRU to do memory access. This definitely wrong. Besides, should we consider host's setting when=20 guest is running? --=20 best regards yang