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

[Tim Deegan <tim@xxxxxxx>]

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.

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.

> >>>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?

> 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?

Cheers,

Tim.

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