linux-kernel - Re: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive

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: <404f0944-d514-b450-f743-89ae798ac694@arm.com>
Date:   Fri, 7 Sep 2018 18:55:45 +0100
From:   Jean-Philippe Brucker <jean-philippe.brucker@....com>
To:     Jerome Glisse <jglisse@...hat.com>,
        Kenneth Lee <liguozhu@...ilicon.com>
Cc:     Kenneth Lee <nek.in.cn@...il.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>, kvm@...r.kernel.org,
        Jonathan Corbet <corbet@....net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-doc@...r.kernel.org, Sanjay Kumar <sanjay.k.kumar@...el.com>,
        Hao Fang <fanghao11@...wei.com>, linux-kernel@...r.kernel.org,
        linuxarm@...wei.com, iommu@...ts.linux-foundation.org,
        "David S . Miller" <davem@...emloft.net>,
        linux-crypto@...r.kernel.org,
        Philippe Ombredanne <pombredanne@...b.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-accelerators@...ts.ozlabs.org
Subject: Re: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive

On 07/09/2018 17:53, Jerome Glisse wrote:
> So there is no reasons to do that under VFIO. Especialy as in your example
> it is not a real user space device driver, the userspace portion only knows
> about writting command into command buffer AFAICT.
> 
> VFIO is for real userspace driver where interrupt, configurations, ... ie
> all the driver is handled in userspace. This means that the userspace have
> to be trusted as it could program the device to do DMA to anywhere (if
> IOMMU is disabled at boot which is still the default configuration in the
> kernel).

If the IOMMU is disabled (not exactly a kernel default by the way, I
think most IOMMU drivers enable it by default), your userspace driver
can't bypass DMA isolation by accident. It just won't be allowed to
access the device. VFIO requires an IOMMU unless the admin forces the
NOIOMMU mode with the "enable_unsafe_noiommu_mode" module parameter, and
the userspace explicitly asks for it with VFIO_NOIOMMU_IOMMU, which
taints the kernel. Not for production. A normal userspace driver that
uses VFIO can only do DMA to its own memory.

Thanks,
Jean