linux-kernel - Re: [PATCH v3 2/5] rust: dma: add type alias for bindings::dma_addr

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: <3CC4D02A-9A15-4F98-8DB1-97B457C18E95@collabora.com>
Date: Tue, 26 Aug 2025 16:58:48 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: akpm@...ux-foundation.org,
 ojeda@...nel.org,
 alex.gaynor@...il.com,
 boqun.feng@...il.com,
 gary@...yguo.net,
 bjorn3_gh@...tonmail.com,
 lossin@...nel.org,
 a.hindborg@...nel.org,
 aliceryhl@...gle.com,
 tmgross@...ch.edu,
 abdiel.janulgue@...il.com,
 acourbot@...dia.com,
 jgg@...pe.ca,
 lyude@...hat.com,
 robin.murphy@....com,
 rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/5] rust: dma: add type alias for bindings::dma_addr_t

> On 26 Aug 2025, at 14:33, Danilo Krummrich <dakr@...nel.org> wrote:
> 
> On Tue Aug 26, 2025 at 7:15 PM CEST, Daniel Almeida wrote:
>> Hmm, I wonder if this shouldn’t be its own type, instead of an alias. This
>> will be handy if we want to enforce that a given address is, in fact, a bus
>> address.
> 
> I'm not sure I understand the idea. How can a new type compared to a type alias
> help to guarantee that a DMA address is also a bus address?
> 
> This depends on whether there is an IOMMU, etc.

I was referring to the term "bus address" as used here [0].

My understanding has always been that a dma_addr_t is a bus address regardless
of whether the system has an iommu? If there's no IOMMU then we there's a 1:1
correspondence but this doesn't invalidate the use of the term? i.e.: it's still
an address that can be directly accessed by a hardware device.

In any case, this is a bit orthogonal to the point I was trying to make, my bad
for not expressing it better.

What I mean is, by using a separate type, i.e.:

DmaAddress(bindings::dma_addr_t)

we now ensure that one cannot pass a random u32/u64 value where a DmaAddress is
expected. It's a bit like the __iomem or __user C annotation, but actually
enforced by the type system.

In fact, this is something that was recently done in uaccess.rs, IIRC.

[0]: https://docs.kernel.org/core-api/dma-api-howto.html#cpu-and-dma-addresses