linux-kernel - Re: [PATCH v3 00/11] KVM: x86: track guest page access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56CBCBC1.8050902@intel.com>
Date:	Tue, 23 Feb 2016 11:02:25 +0800
From:	Jike Song <jike.song@...el.com>
To:	Xiao Guangrong <guangrong.xiao@...ux.intel.com>
CC:	Paolo Bonzini <pbonzini@...hat.com>, gleb@...nel.org,
	mtosatti@...hat.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, kai.huang@...ux.intel.com,
	Andrea Arcangeli <aarcange@...hat.com>,
	"Tian, Kevin" <kevin.tian@...el.com>
Subject: Re: [PATCH v3 00/11] KVM: x86: track guest page access

+Kevin

On 02/22/2016 06:05 PM, Xiao Guangrong wrote:
> 
> On 02/19/2016 08:00 PM, Paolo Bonzini wrote:
>>
>> I still have a doubt: how are you going to handle invalidation of GPU
>> shadow page tables if a device (emulated in QEMU or even vhost) does DMA
>> to the PPGTT?
> 
> I think Jike is the better one to answer this question, Jike, could you
> please clarify it? :)
> 

Sure :)

Actually in guest PPGTT is manipulated by CPU rather than GPU. The
PPGTT page table itself are plain memory, composed & modified by the
GPU driver, i.e. by CPU in Non-Root mode.

Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT
violation rather than DMA fault happens.

>> Generally, this was the reason to keep stuff out of KVM
>> and instead hook into the kernel mm subsystem (as with userfaultfd).
> 
> We considered it carefully but this way can not satisfy KVMGT's requirements.
> The reasons i explained in the old thread (https://lkml.org/lkml/2015/12/1/516)
> are:
> 
> "For the performance, shadow GPU is performance critical and requires
> frequently being switched, it is not good to handle it in userspace. And
> windows guest has many GPU tables and updates it frequently, that means,
> we need to write protect huge number of pages which are single page based,
> I am afraid userfaultfd can not handle this case efficiently.
> 
> For the functionality, userfaultfd can not fill the need of shadow page
> because:
> - the page is keeping readonly, userfaultfd can not fix the fault and let
>     the vcpu progress (write access causes writeable gup).
> 
> - the access need to be emulated, however, userfaultfd/kernel does not have
>     the ability to emulate the access as the access is trigged by guest, the
>     instruction info is stored in VMCS so that only KVM can emulate it.
> 
> - shadow page needs to be notified after the emulation is finished as it
>     should know the new data written to the page to update its page hierarchy.
>     (some hardwares lack the 'retry' ability so the shadow page table need to
>      reflect the table in guest at any time). "
> 
> Any idea?
> 

--
Thanks,
Jike