From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQglc-0001kQ-AV for qemu-devel@nongnu.org; Tue, 02 Feb 2016 14:37:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQglY-0002su-9e for qemu-devel@nongnu.org; Tue, 02 Feb 2016 14:37:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQglY-0002sT-1c for qemu-devel@nongnu.org; Tue, 02 Feb 2016 14:37:32 -0500 Message-ID: <1454441849.30910.5.camel@redhat.com> From: Alex Williamson Date: Tue, 02 Feb 2016 12:37:29 -0700 In-Reply-To: <003AAFE53969E14CB1F09B6FD68C3CD47BB6CB3B@ORSMSX106.amr.corp.intel.com> References: <1451994098-6972-1-git-send-email-kraxel@redhat.com> <1454009759.7183.7.camel@redhat.com> <003AAFE53969E14CB1F09B6FD68C3CD47BB669D2@ORSMSX106.amr.corp.intel.com> <1454036094.23148.9.camel@redhat.com> <003AAFE53969E14CB1F09B6FD68C3CD47BB67D8B@ORSMSX106.amr.corp.intel.com> <003AAFE53969E14CB1F09B6FD68C3CD47BB6CB3B@ORSMSX106.amr.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Kay, Allen M" , "Tian, Kevin" , Gerd Hoffmann , "qemu-devel@nongnu.org" Cc: "igvt-g@ml01.01.org" , "xen-devel@lists.xensource.com" , Eduardo Habkost , Stefano Stabellini , Cao jin , "vfio-users@redhat.com" On Tue, 2016-02-02 at 19:10 +0000, Kay, Allen M wrote: >=C2=A0 > > -----Original Message----- > > From: Tian, Kevin > > Sent: Monday, February 01, 2016 11:08 PM > > To: Kay, Allen M; Alex Williamson; Gerd Hoffmann; qemu-devel@nongnu.o= rg > > Cc: igvt-g@ml01.01.org; xen-devel@lists.xensource.com; Eduardo Habkos= t; > > Stefano Stabellini; Cao jin; vfio-users@redhat.com > > Subject: RE: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough c= hipset > > tweaks > >=C2=A0 > > > From: Kay, Allen M > > > Sent: Saturday, January 30, 2016 5:58 AM > > >=C2=A0 > > > First of all, I would like to clarify I'm talking about general IGD > > > passthrough case - not specific to KVMGT.=C2=A0=C2=A0In IGD passthr= ough > > > configuration, one of the following will happen when the driver acc= esses > > OpRegion: > > >=C2=A0 > > > 1) If the hypervisor sets up OpRegion GPA/HPA mapping, either by > > > pre-map it (i.e. Xen) or map it during EPT page fault (i.e. KVM), > > > guest can successfully read the content of the OpRegion and check t= he ID > > string.=C2=A0=C2=A0In this case, everything works fine. > > >=C2=A0 > > > 2) if the hypervisor does not setup OpRegion GPA/HPA mapping at all= , > > > then guest driver's attempt to setup GVA/GPA mapping will fail, whi= ch > > > causes the driver to fail.=C2=A0=C2=A0In this case, guest driver wo= n't have the > > > opportunity to look into the content of OpRegion memory and check t= he ID > > string. > > >=C2=A0 > >=C2=A0 > > Guest mapping of GVA->GPA can always succeed regardless of whether > > GPA->HPA is valid. Failure will happen only when the GVA is actually > > accessed by guest. > >=C2=A0 Hi Allen, > That is the data from team debugged IGD passthrough on a closed source = hypervisor that does not map OpRegion with EPT.=C2=A0=C2=A0The end result= is the same -driver cannot access inside of OpRegion without > failing. Define "failing". > > I don't understand 2). If hypervisor doesn't want to setup mapping, t= here is > > no chance for guest driver to get opregion content, right? >=C2=A0 > That was precisely the point I was trying to make.=C2=A0=C2=A0As a resu= lt, guest driver needs some indication from the hypervisor that the addre= ss at 0xFC contains GPA that can be safely accessed by the > driver without causing unrecoverable failure on hypervisors that does n= ot map OpRegion - by leaving HPA address at 0xFC. I think the thing that doesn't make sense to everyone here is that it's common practice for x86 systems, especially legacy OSes, to probe memory, get back -1 and move on.=C2=A0=C2=A0A hypervisor should support t= hat.=C2=A0=C2=A0So if there's a bogus address in the ASL Storage register and the driver tries to read from the GPA indicated by that address, the VM should at worst get back -1 or a memory space that doesn't contain the graphics signature.=C2=A0=C2=A0If there's a super strict hypervisor that doesn't h= andle the VM faulting outside of it's address space, that's very prone to exploit. If a driver wants to avoid it anyway, perhaps they should be doing standard things like checking whether the ASL Storage address falls within a reserved memory region rather than coming up with ad-hoc register content based solutions.=C2=A0=C2=A0Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks Date: Tue, 02 Feb 2016 12:37:29 -0700 Message-ID: <1454441849.30910.5.camel@redhat.com> References: <1451994098-6972-1-git-send-email-kraxel@redhat.com> <1454009759.7183.7.camel@redhat.com> <003AAFE53969E14CB1F09B6FD68C3CD47BB669D2@ORSMSX106.amr.corp.intel.com> <1454036094.23148.9.camel@redhat.com> <003AAFE53969E14CB1F09B6FD68C3CD47BB67D8B@ORSMSX106.amr.corp.intel.com> <003AAFE53969E14CB1F09B6FD68C3CD47BB6CB3B@ORSMSX106.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <003AAFE53969E14CB1F09B6FD68C3CD47BB6CB3B@ORSMSX106.amr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: "Kay, Allen M" , "Tian, Kevin" , Gerd Hoffmann , "qemu-devel@nongnu.org" Cc: "igvt-g@ml01.01.org" , "xen-devel@lists.xensource.com" , Eduardo Habkost , Stefano Stabellini , Cao jin , "vfio-users@redhat.com" List-Id: xen-devel@lists.xenproject.org On Tue, 2016-02-02 at 19:10 +0000, Kay, Allen M wrote: >=C2=A0 > > -----Original Message----- > > From: Tian, Kevin > > Sent: Monday, February 01, 2016 11:08 PM > > To: Kay, Allen M; Alex Williamson; Gerd Hoffmann; qemu-devel@nongnu.o= rg > > Cc: igvt-g@ml01.01.org; xen-devel@lists.xensource.com; Eduardo Habkos= t; > > Stefano Stabellini; Cao jin; vfio-users@redhat.com > > Subject: RE: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough c= hipset > > tweaks > >=C2=A0 > > > From: Kay, Allen M > > > Sent: Saturday, January 30, 2016 5:58 AM > > >=C2=A0 > > > First of all, I would like to clarify I'm talking about general IGD > > > passthrough case - not specific to KVMGT.=C2=A0=C2=A0In IGD passthr= ough > > > configuration, one of the following will happen when the driver acc= esses > > OpRegion: > > >=C2=A0 > > > 1) If the hypervisor sets up OpRegion GPA/HPA mapping, either by > > > pre-map it (i.e. Xen) or map it during EPT page fault (i.e. KVM), > > > guest can successfully read the content of the OpRegion and check t= he ID > > string.=C2=A0=C2=A0In this case, everything works fine. > > >=C2=A0 > > > 2) if the hypervisor does not setup OpRegion GPA/HPA mapping at all= , > > > then guest driver's attempt to setup GVA/GPA mapping will fail, whi= ch > > > causes the driver to fail.=C2=A0=C2=A0In this case, guest driver wo= n't have the > > > opportunity to look into the content of OpRegion memory and check t= he ID > > string. > > >=C2=A0 > >=C2=A0 > > Guest mapping of GVA->GPA can always succeed regardless of whether > > GPA->HPA is valid. Failure will happen only when the GVA is actually > > accessed by guest. > >=C2=A0 Hi Allen, > That is the data from team debugged IGD passthrough on a closed source = hypervisor that does not map OpRegion with EPT.=C2=A0=C2=A0The end result= is the same -driver cannot access inside of OpRegion without > failing. Define "failing". > > I don't understand 2). If hypervisor doesn't want to setup mapping, t= here is > > no chance for guest driver to get opregion content, right? >=C2=A0 > That was precisely the point I was trying to make.=C2=A0=C2=A0As a resu= lt, guest driver needs some indication from the hypervisor that the addre= ss at 0xFC contains GPA that can be safely accessed by the > driver without causing unrecoverable failure on hypervisors that does n= ot map OpRegion - by leaving HPA address at 0xFC. I think the thing that doesn't make sense to everyone here is that it's common practice for x86 systems, especially legacy OSes, to probe memory, get back -1 and move on.=C2=A0=C2=A0A hypervisor should support t= hat.=C2=A0=C2=A0So if there's a bogus address in the ASL Storage register and the driver tries to read from the GPA indicated by that address, the VM should at worst get back -1 or a memory space that doesn't contain the graphics signature.=C2=A0=C2=A0If there's a super strict hypervisor that doesn't h= andle the VM faulting outside of it's address space, that's very prone to exploit. If a driver wants to avoid it anyway, perhaps they should be doing standard things like checking whether the ASL Storage address falls within a reserved memory region rather than coming up with ad-hoc register content based solutions.=C2=A0=C2=A0Thanks, Alex