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] [day] [month] [year] [list]
Message-ID: <CANiq72mS-AgdAva4mB=FWf5dh3vZg95Ka7Wv36ypoZXChuwk=A@mail.gmail.com>
Date: Thu, 6 Feb 2025 17:11:52 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Guangbo Cui <2407018371@...com>
Cc: Alice Ryhl <aliceryhl@...gle.com>, daniel.almeida@...labora.com, 
	a.hindborg@...nel.org, alex.gaynor@...il.com, benno.lossin@...ton.me, 
	bjorn3_gh@...tonmail.mco, boqun.feng@...il.com, boris.brezillon@...labora.com, 
	dakr@...nel.org, gary@...yguo.net, gregkh@...uxfoundation.org, 
	linux-kernel@...r.kernel.org, ojeda@...nel.org, rafael@...nel.org, 
	robh@...nel.org, rust-for-linux@...r.kernel.org, tmgross@...ch.edu
Subject: Re: [PATCH v6 2/3] rust: io: mem: add a generic iomem abstraction

On Thu, Feb 6, 2025 at 4:59 PM Guangbo Cui <2407018371@...com> wrote:
>
> With CONFIG_RUST_BUILD_ASSERT_ALLOW=y enabled, this compilation succeeds.

Yes, that is expected too (but note that the config option is there
just in case -- it should not happen that it is needed in normal
builds).

> Even if the size is determined at compile time, the compilation will still fail
> if CONFIG_RUST_BUILD_ASSERT_ALLOW is not enabled.

Yes, that is expected -- the idea is that you cannot make the mistake
of calling those.

I think you are suggesting only exposing the methods in the case where
calling them would work? That would be great if a design allows for
it, of course.

By the way, Daniel, in patch 3/3 there is this comment:

+    ///     // Unlike `ioremap_resource_sized`, here the size of the
memory region
+    ///     // is not known at compile time, so only the `try_read*`
and `try_write*`
+    ///     // family of functions are exposed, leading to runtime
checks on every
+    ///     // access.

Is the "only ... are exposed" correct? i.e. are they exposed? / is
this potentially confusing?

Thanks!

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ