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: <Z_zwZYBO5Txz6lDF@infradead.org>
Date: Mon, 14 Apr 2025 04:24:21 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc: Christoph Hellwig <hch@...radead.org>,
	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 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 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.