[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [v7][RFC][PATCH 01/13] xen: RMRR fix

This series of patches try to reconcile those remaining problems but
just post as RFC to ask for any comments to refine everything.

The current whole scheme is as follows:

1. Reconcile guest mmio with RMRR in pci_setup
2. Reconcile guest RAM with RMRR in e820 table

Then in theory guest wouldn't access any RMRR range.

3. Just initialize all RMRR ranges as p2m_access_n in p2m table:

Here I think we shouldn't set 1:1 to expose RMRR to guest if guest
may never have a device assignment. It can prevent from leaking RMRR.

4. We reset those mappings as 1:1:p2m_mmio_direct:p2m_ram_rw once we
have a device assignment.

5. Before we take real device assignment, any access to RMRR may issue
ept_handle_violation because of p2m_access_n. Then we just call
update_guest_eip() to return.

6. After a device assignment, guest may maliciously access RMRR ranges
although we already reserve in e820 table. In the worst-case scenario
just that device can't work well. But this behavior should be same as
native so I think we shouldn't do anything here.

7. Its not necessary to introduce any flag in ept_set_entry.

First of all, hypervisor/dom0 should be trusted. Any user should make
sure they never override any valid RMRR tables without any check. So
our original set_identity_p2m_entry() tries to set as follows:

 - gfn space unoccupied -> insert mapping; success.
 - gfn space already occupied by 1:1 RMRR mapping -> do nothing; success.
 - gfn space already occupied by other mapping -> fail.

Now in our case we add a rule:
 - if p2m_access_n is set we also set this mapping.

Another reason is that ept_set_entry is called in many scenarios to
support its own management, I think we shouldn't corrupt this mechanism
and its also difficult to cover all points.

8. We need to take a consideration grouping all devices that have same
RMRR range to make sure they're just assigned to one VM.

Jan Beulich (1):
      introduce XENMEM_reserved_device_memory_map

Tiejun Chen (12):
      tools/libxc: introduce hypercall for xc_reserved_device_memory_map
      tools/libxc: check if modules space is overlapping with reserved device 
      hvmloader/util: get reserved device memory maps
      hvmloader/mmio: reconcile guest mmio with reserved device memory
      hvmloader/ram: check if guest memory is out of reserved device memory maps
      xen/x86/p2m: introduce p2m_check_reserved_device_memory
      xen/x86/p2m: set p2m_access_n for reserved device memory mapping
      xen/x86/ept: handle reserved device memory in ept_handle_violation
      xen/x86/p2m: introduce set_identity_p2m_entry
      xen:vtd: create RMRR mapping
      xen/vtd: re-enable USB device assignment
      xen/vtd: group assigned device with RMRR

 tools/firmware/hvmloader/e820.c      | 215 
 tools/firmware/hvmloader/pci.c       |  68 
 tools/firmware/hvmloader/util.c      |  66 
 tools/firmware/hvmloader/util.h      |   6 +++++
 tools/libxc/include/xenctrl.h        |   4 +++
 tools/libxc/xc_domain.c              |  29 +++++++++++++++++++++
 tools/libxc/xc_hvm_build_x86.c       | 111 
 xen/arch/x86/hvm/vmx/vmx.c           |  14 +++++++++++
 xen/arch/x86/mm/p2m.c                |  52 
 xen/common/compat/memory.c           |  52 
 xen/common/memory.c                  |  49 ++++++++++++++++++++++++++++++++++++
 xen/drivers/passthrough/iommu.c      |  10 ++++++++
 xen/drivers/passthrough/vtd/dmar.c   |  46 +++++++++++++++++++++++++++++++++-
 xen/drivers/passthrough/vtd/dmar.h   |   3 ++-
 xen/drivers/passthrough/vtd/extern.h |   1 +
 xen/drivers/passthrough/vtd/iommu.c  |  93 
 xen/drivers/passthrough/vtd/utils.c  |   7 ------
 xen/include/asm-x86/p2m.h            |  17 +++++++++++++
 xen/include/public/memory.h          |  24 +++++++++++++++++-
 xen/include/xen/iommu.h              |   4 +++
 xen/include/xlat.lst                 |   3 ++-
 21 files changed, 828 insertions(+), 46 deletions(-)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.