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: <DGAE0M87A8X8.3OWL23XSZF7I6@kernel.org>
Date: Mon, 09 Feb 2026 12:17:08 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Lyude Paul" <lyude@...hat.com>
Cc: <linux-kernel@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
 <rust-for-linux@...r.kernel.org>, <nouveau@...ts.freedesktop.org>, "Daniel
 Almeida" <daniel.almeida@...labora.com>, "Gary Guo" <gary@...yguo.net>,
 "Benno Lossin" <lossin@...nel.org>, "Alexandre Courbot"
 <acourbot@...dia.com>, "Janne Grunau" <j@...nau.net>
Subject: Re: [PATCH v7 6/7] rust: Introduce iosys_map bindings

On Fri Feb 6, 2026 at 11:34 PM CET, Lyude Paul wrote:
> +/// Raw unsized representation of a `struct iosys_map`.
> +///
> +/// This struct is a transparent wrapper around `struct iosys_map`. The C API does not provide the
> +/// size of the mapping by default, and thus this type also does not include the size of the
> +/// mapping. As such, it cannot be used for actually accessing the underlying data pointed to by the
> +/// mapping.
> +///
> +/// With the exception of kernel crates which may provide their own wrappers around `RawIoSysMap`,
> +/// users will typically not interact with this type directly.
> +#[repr(transparent)]
> +pub struct RawIoSysMap<const SIZE: usize = 0>(bindings::iosys_map);

I'm still against using struct iosys_map as a common frontend for I/O memory and
system memory.

Exposing this as another I/O backend instead of just having a Rust structure as
frontend for a "real" abstraction around the Rust backends has various
downsides.

  (1) We are limited to the features of struct iosys_map. The corresponding Rust
      backends may provide additional functionality, which we can't access with
      struct iosys_map. For instance, they Mmio will provide a relaxed() method
      providing access to a borrowed backend providing relaxed ordering
      accessors.

  (2) We loose out on the capability to consider compile time checks regarding
      the guaranteed minimum size of the mapping. (To be fair this could be
      implemented on `IoSysMap` itself as well, but it would duplicate code that
      we already have in the corresponding backends.)

  (3) You have to duplicate the safety requirements of the backends that struct
      iosys_map wraps. In fact, this series ignores that if the backend is I/O
      memory we have to guarantee the it is revoked when the device this I/O
      memory originates from is unbound.

Having a look at patch 7, it should be possible to read `is_iomem` and `vaddr` /
`vaddr_iomem` from the struct iosys_map and just construct the "real" `Mmio`
backend from it. We also have to create a backend for normal system memory, but
that should be trivial. :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ