linux-kernel - Re: [PATCH] vfio: Include No-IOMMU mode

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1447693613.3946.258.camel@redhat.com>
Date:	Mon, 16 Nov 2015 10:06:53 -0700
From:	Alex Williamson <alex.williamson@...hat.com>
To:	"alex.williamson" <alex.williamson@...hat.com>
Cc:	avi@...lladb.com, avi@...udius-systems.com, gleb@...lladb.com,
	corbet@....net, bruce.richardson@...el.com, mst@...hat.com,
	linux-kernel@...r.kernel.org, alexander.duyck@...il.com,
	gleb@...udius-systems.com, stephen@...workplumber.org,
	vladz@...udius-systems.com, iommu@...ts.linux-foundation.org,
	hjk@...sjkoch.de, gregkh@...uxfoundation.org
Subject: Re: [PATCH] vfio: Include No-IOMMU mode

On Wed, 2015-10-28 at 15:21 -0600, Alex Williamson wrote:
> There is really no way to safely give a user full access to a DMA
> capable device without an IOMMU to protect the host system.  There is
> also no way to provide DMA translation, for use cases such as device
> assignment to virtual machines.  However, there are still those users
> that want userspace drivers even under those conditions.  The UIO
> driver exists for this use case, but does not provide the degree of
> device access and programming that VFIO has.  In an effort to avoid
> code duplication, this introduces a No-IOMMU mode for VFIO.
> 
> This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
> the "enable_unsafe_noiommu_mode" option on the vfio driver.  This
> should make it very clear that this mode is not safe.  Additionally,
> CAP_SYS_RAWIO privileges are necessary to work with groups and
> containers using this mode.  Groups making use of this support are
> named /dev/vfio/noiommu-$GROUP and can only make use of the special
> VFIO_NOIOMMU_IOMMU for the container.  Use of this mode, specifically
> binding a device without a native IOMMU group to a VFIO bus driver
> will taint the kernel and should therefore not be considered
> supported.  This patch includes no-iommu support for the vfio-pci bus
> driver only.
> 
> Signed-off-by: Alex Williamson <alex.williamson@...hat.com>
> ---
> 
> This is pretty well the same as RFCv2, I've changed the pr_warn to a
> dev_warn and added another, printing the pid and comm of the task when
> it actually opens the device.  If Stephen can port the driver code
> over and prove that this actually works sometime next week, and there
> aren't any objections to this code, I'll include it in a pull request
> for the next merge window.  MST, I dropped your ack due to the
> changes, but I'll be happy to add it back if you like.  Thanks,
> 
> Alex
> 
>  drivers/vfio/Kconfig        |   15 +++
>  drivers/vfio/pci/vfio_pci.c |    8 +-
>  drivers/vfio/vfio.c         |  186 ++++++++++++++++++++++++++++++++++++++++++-
>  include/linux/vfio.h        |    3 +
>  include/uapi/linux/vfio.h   |    7 ++
>  5 files changed, 209 insertions(+), 10 deletions(-)

FYI, this is now in v4.4-rc1 (the slightly modified v2 version).  I want
to give fair warning though that while we seem to agree on this idea, it
hasn't been proven with a userspace driver port.  I've opted to include
it in this merge window rather than delaying it until v4.5, but I really
need to see a user for this before the end of the v4.4 cycle or I think
we'll need to revert and revisit for v4.5 anyway.  I don't really have
any interest in adding and maintaining code that has no users.  Please
keep me informed of progress with a dpdk port.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/