linux-kernel - Re: [PATCH v13 2/6] rust: introduce module

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: <87o6u3vw04.fsf@kernel.org>
Date: Wed, 02 Jul 2025 10:26:35 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Benno Lossin" <lossin@...nel.org>,  "Miguel Ojeda" <ojeda@...nel.org>,
  "Alex Gaynor" <alex.gaynor@...il.com>,  "Boqun Feng"
 <boqun.feng@...il.com>,  "Gary Guo" <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Alice Ryhl" <aliceryhl@...gle.com>,
  "Masahiro Yamada" <masahiroy@...nel.org>,  "Nathan Chancellor"
 <nathan@...nel.org>,  "Luis Chamberlain" <mcgrof@...nel.org>,  "Danilo
 Krummrich" <dakr@...nel.org>,  "Nicolas Schier"
 <nicolas.schier@...ux.dev>,  "Trevor Gross" <tmgross@...ch.edu>,  "Adam
 Bratschi-Kaye" <ark.email@...il.com>,  <rust-for-linux@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>,  <linux-kbuild@...r.kernel.org>,  "Petr
 Pavlu" <petr.pavlu@...e.com>,  "Sami Tolvanen" <samitolvanen@...gle.com>,
  "Daniel Gomez" <da.gomez@...sung.com>,  "Simona Vetter"
 <simona.vetter@...ll.ch>,  "Greg KH" <gregkh@...uxfoundation.org>,  "Fiona
 Behrens" <me@...enk.dev>,  "Daniel Almeida"
 <daniel.almeida@...labora.com>,  <linux-modules@...r.kernel.org>
Subject: Re: [PATCH v13 2/6] rust: introduce module_param module

"Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:

> On Tue, Jul 1, 2025 at 5:43 PM Benno Lossin <lossin@...nel.org> wrote:
>>
>> Ultimately this is something for Miguel to decide.
>
> Only if you all cannot get to an agreement ;)

>
> If Andreas wants to have it already added, then I would say just mark
> it `unsafe` as Benno recommends (possibly with an overbearing
> precondition), given it has proven subtle/forgettable enough and that,
> if I understand correctly, it would actually become unsafe if someone
> "just" added "reasonably-looking code" elsewhere.

You are right that if someone added code to the API, the API could
become unsound. But that is the deal with all our APIs and I don't agree
that the details are very subtle here. Someone would need to add sysfs
support or user provided parameter parsing to cause the unsoundness we
are talking about.

Anyone attempting such a task should have proper understanding of the
code first, and given the ample amount of `NOTE` comments I have added,
it should be clear that the concurrent accesses that this addition would
introduce, needs to be accounted for, to avoid data races.

I will add myself as a reviewer for the rust module parameter parsing
code if that is OK with module maintainers.

> That way we have an incentive to make it safe later on and, more
> importantly, to think again about it when such a patch lands,
> justifying it properly. And it could plausibly protect out-of-tree
> users, too.

Again, I do not think it is reasonable to mark this function unsafe.

> This is all assuming that we will not have many users of this added
> right away (in a cycle or two), i.e. assuming it will be easy to
> change callers later on (if only to remove the `unsafe {}`).

rnull will use this the cycle after it is merged.



Best regards,
Andreas Hindborg