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

[Alex Williamson <alex.williamson@xxxxxxxxxx>]

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@xxxxxxxxxx
> > Cc: igvt-g@xxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; Eduardo Habkost;
> > Stefano Stabellini; Cao jin; vfio-users@xxxxxxxxxx
> > 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel