Re: [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 2016-02-02 at 19:10 +0000, Kay, Allen M wrote:
> 
> > -----Original Message-----
> > From: Tian, Kevin
> > Sent: Monday, February 01, 2016 11:08 PM
> > To: Kay, Allen M; Alex Williamson; 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
> > Subject: RE: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> > tweaks
> > 
> > > From: Kay, Allen M
> > > Sent: Saturday, January 30, 2016 5:58 AM
> > > 
> > > First of all, I would like to clarify I'm talking about general IGD
> > > passthrough case - not specific to KVMGT.  In IGD passthrough
> > > configuration, one of the following will happen when the driver accesses
> > OpRegion:
> > > 
> > > 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 the ID
> > string.  In this case, everything works fine.
> > > 
> > > 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, which
> > > causes the driver to fail.  In this case, guest driver won't have the
> > > opportunity to look into the content of OpRegion memory and check the ID
> > string.
> > > 
> > 
> > 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.
> > 

Hi Allen,

> That is the data from team debugged IGD passthrough on a closed source hypervisor that does not map OpRegion with EPT.  The 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, there is
> > no chance for guest driver to get opregion content, right?
> 
> That was precisely the point I was trying to make.  As a result, guest driver needs some indication from the hypervisor that the address at 0xFC contains GPA that can be safely accessed by the
> driver without causing unrecoverable failure on hypervisors that does not 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.  A hypervisor should support that.  So
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.  If there's a super strict hypervisor that doesn't handle 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.  Thanks,

Alex