Re: [Xen-devel] (v2) Design proposal for RMRR fix

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, January 08, 2015 8:32 PM
> 
> Hi Kevin,
> 
> Thanks for sending out this design document.  I think Jan will have
> the most to say about this.  Looking just at the hypervisor side of
> things, and leaving the tools desig to others...
> 
> At 11:23 +0000 on 26 Dec (1419589382), Tian, Kevin wrote:
> > c) in Xen hypervisor it is reasonable to fail upon confliction, where
> > device is actually assigned. But due to the same requirement on USB
> > controller, sometimes we might want it succeed just w/ warnings.
> 
> Can you explain more concretely why we would want to allow assignment
> whn the RMRR setup fails?  It seems like the device's use of the RMRR
> will (at least) corrupt the OS and (possibly) make the device itself
> fail.

For USB device, RMRR is used only in early-boot phase, as a way for
communication between legacy keyboard driver and bios. That emulation
mode will be disabled either at some ACPI initialization step or when
USB keyboard driver is loader (sorry don't remember detail). So when
it's assigned to a guest, there's no legacy emulation and not setting up
identity mapping is not a critical issue. If we think such usage case is
a valid one, 'fail' would cause regression on that.

> 
> If we do need to allow this, it should be configured for a particular
> device, rather than just disabling the safety checks for all devices at
> once.

will think about this. we still have safety checks, and the open is whether
fail immediately or just warn users that assigned device might have
problem but it's his call to decide whether moving forward. If overall
warning is OK, then we don't need per-device policy. But if all think
fail should be the default option, then yes we need per-device policy
to support the relaxed option.

> 
> > >>>3.4 Xen: setup RMRR identity mapping
> > ----
> > Regardless of whether userspace has detected confliction, Xen hypervisor
> > always needs to detect confliction itself when setting up identify
> > mapping for reserved gfn regions, following above defined policy.
> >
> > Identity mapping should be really handled from the general p2m layer,
> > so the same r/w permissions apply equally to CPU/DMA access paths,
> > regardless of the underlying fact whether EPT is shared with IOMMU.
> 
> Agreed!
> 
> > >>>3.8 Xen: Handle devices sharing reserved regions
> > ----
> > Per VT-d spec, it's possible to have two devices sharing same reserved
> > region. Though we didn't see such example in reality, hypervisor needs
> > to detect and handle such scenario, otherwise vulnerability may exist
> > if two devices are assigned to different VMs (so a malicious VM may
> > program its assigned device to clobber the shared region to malform
> > another VM's device)
> >
> > Ideally all devices sharing reserved regions should be assigned to a
> > single VM. However achieving this goal can't be done sole in hypervisor
> > w/o reworking current device assignment interface. Assignment is managed
> > by toolstack, which requires exposing group sharing information to
> > userspace and then extends toolstack to manage assignment in bundle.
> 
> Xen can at least enforce that devices that share RMRR are not assigned
> to different domains.  Is the problem here that "unassigned" devices
> are actually assigned to dom0?

yes, that's why we said Xen will check and fail the assignment of this device
if other devices sharing same RMRR regions have been assigned to other
VMs (e.g. dom0).

> 
> > Given the problem only in ideal space, we propose to not support such
> > scenario, i.e. having hypervisor to fail the assignment, if the target
> > device happens to share some reserved regions with another device,
> > following [Guideline-4] to keep things simple.
> 
> How confident are you that this doesn't happen in real servers?  What
> sort of range of servers have you been able to check?

We didn't do one-time check on many servers. It's based on our experience
working on VT-d in past years. If it turns out to be a real problem later, we
can redesign the assignment interface to allow group assignment. For now
we think it's enough to enforce check in Xen. :-)

> 
> Cheers,
> 
> Tim.

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