linux-kernel - Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

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: <8f55367e-45c0-4280-b1ed-7ce9160c1fad@ti.com>
Date: Mon, 14 Apr 2025 12:08:44 -0500
From: Andrew Davis <afd@...com>
To: Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Christoph Hellwig
	<hch@...radead.org>
CC: Bastien Curutchet <bastien.curutchet@...tlin.com>,
        Sumit Semwal
	<sumit.semwal@...aro.org>,
        Christian König
	<christian.koenig@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <linaro-mm-sig@...ts.linaro.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.

On 4/14/25 6:48 AM, Thomas Petazzoni wrote:
> Hello Christoph,
> 
> On Mon, 14 Apr 2025 04:24:21 -0700
> Christoph Hellwig <hch@...radead.org> wrote:
> 
>> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
>>> What this patch series is about is to add new user-space interface to
>>> extend the existing UIO subsystem.
>>
>> Which as I explained to you is fundamentally broken and unsafe.  If you
>> need to do DMA from userspae you need to use vfio/iommufd.
> 
> I'm still unclear as to why it is more "broken and unsafe" than UIO
> already is. As I already replied in this thread: UIO allows to remap
> MMIO registers into a user-space application, which can then do
> whatever it wants with the IP block behind those MMIO registers. If
> this IP block supports DMA, it already means that _today_ with the
> current UIO subsystem as it is, the user-space application can program
> a DMA transfer to read/write to any location in memory.
> 
> Therefore, providing a way to cleanly allocate DMA buffers and get
> their physical address will not make things any better or worse in
> terms of safety.
> 
> The fact that it is reasonably safe is solely based on access control
> to the UIO device, done using usual Unix permissions, and that is
> already the case today.
> 
>>> I am not sure how this can work in our use-case. We have a very simple
>>> set of IP blocks implemented in a FPGA, some of those IP blocks are
>>> able to perform DMA operations. The register of those IP blocks are
>>> mapped into a user-space application using the existing, accepted
>>> upstream, UIO subsystem. Some of those registers allow to program DMA
>>> transfers. So far, we can do all what we need, except program those DMA
>>> transfers. Lots of people are having the same issue, and zillions of
>>> ugly out-of-tree solutions flourish all over, and we're trying to see
>>> if we can constructively find a solution that would be acceptable
>>> upstream to resolve this use-case. Our platform is an old PowerPC with
>>> no IOMMU.
>>
>> Then your driver design can't work and you need to replace it with a
>> proper in-kernel driver.
> 
> See above: your point is moot because providing capabilities to
> allocate a buffer and get its physical address so that a UIO-based
> user-space application can do DMA transfer does not make things any
> more unsafe than they already are.
> 

"UIO is a broken legacy mess, so let's add more broken things
to it as broken + broken => still broken, so no harm done", am I
getting that right?

If your FPGA IP can do DMA then you should not be using UIO in
the first place, see UIO docs:

> Please note that UIO is not an universal driver interface. Devices that
> are already handled well by other kernel subsystems (like networking or
> serial or USB) are no candidates for an UIO driver.

The DMA subsystem already handles DMA devices, so write a DMA driver.

Andrew

> Best regards,
> 
> Thomas