linux-kernel - [PATCH 0/5] hv: drivers: Ensure that bridge windows don't overlap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Feb 2016 21:23:57 +0000
From:	jakeo@...rosoft.com
To:	linux-pci@...r.kernel.org, gregkh@...uxfoundation.org,
	kys@...rosoft.com, linux-kernel@...r.kernel.org,
	devel@...uxdriverproject.org, olaf@...fle.de, apw@...onical.com,
	vkuznets@...hat.com, haiyangz@...rosoft.com, haddenh@...rosoft.com
Cc:	Jake Oshins <jakeo@...rosoft.com>
Subject: [PATCH 0/5] hv: drivers: Ensure that bridge windows don't overlap

From: Jake Oshins <jakeo@...rosoft.com>

Hyper-V VMs expose paravirtual drivers through a mechanism called
VMBus, which is managed by hv_vmbus.ko.  For each paravirtual service
instance, this driver exposes a new child device.  Some of these child
devices need memory address space, into which Hyper-V will map things
like the virtual video framebuffer.  This memory-mapped address space
is chosen by the guest OS, not the hypervisor.

This is difficult to map onto the Linux pnp layer, as the code in the
pnp layer to choose MMIO space keys off of bus type and it doesn't know
anything about VMBus.  The maintainers of the pnp layer have asked that
we not offer patches to it that make it understand VMBus, but that we
rather find ways of using the code in its current state.  So hv_vmbus.ko
exports a function, vmbus_allocate_mmio() for choosing the address space
for any child driver that needs this facility.

The recently introduced PCI front-end driver for Hyper-V VMs
(pci-hyperv.ko) uses vmbus_allocate_mmio() for choosing both the region
of memory into which PCI configuration space can be mapped and the
region of memory into which real PCI Express devices which are passed
through to the VM should occupy.  The regions allocated are made to look
like root PCI bus bridge windows to the PCI driver, reusing all the code
in the PCI driver for the rest of the PCI device management.

The problem is that these bridge windows are marked in such a way that
devices can still allocate from the memory space spanned by them, and
this means that if two different PCI buses are created in the VM, each
with devices under them, they may allocate the same memory space, leading
to PCI Base Address Registers which overlap.

This patch series fixes the problem by tracking allocations to child
devices in a separate resource tree, marking them such that the bridge
windows can't overlap.  The main memory resource tree, iomem_resource,
contains resources properly marked as bridge windows, allowing their
children to overlap with them.

Jake Oshins (5):
  hv: Make a function to free mmio regions through vmbus
  hv: Lock access to hyperv_mmio resource tree
  hv: Use new vmbus_mmio_free() from client drivers.
  hv: Reverse order of resources in hyperv_mmio
  hv: Track allocations of children of hv_vmbus in private resource tree

 drivers/hv/vmbus_drv.c          | 56 +++++++++++++++++++++++++++++++++++------
 drivers/pci/host/pci-hyperv.c   | 14 +++++------
 drivers/video/fbdev/hyperv_fb.c |  4 +--
 include/linux/hyperv.h          |  2 +-
 4 files changed, 59 insertions(+), 17 deletions(-)

--
1.9.1