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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DB0U12HAEVZ6.JKFPI2UQHDRY@kernel.org>
Date: Tue, 01 Jul 2025 17:43:29 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Andreas Hindborg" <a.hindborg@...nel.org>
Cc: "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

On Tue Jul 1, 2025 at 4:14 PM CEST, Andreas Hindborg wrote:
> "Benno Lossin" <lossin@...nel.org> writes:
>> On Tue Jul 1, 2025 at 10:43 AM CEST, Andreas Hindborg wrote:
>>> No, I am OK for now with configfs.
>>>
>>> But, progress is still great. How about if we add a copy accessor
>>> instead for now, I think you proposed that a few million emails ago:
>>>
>>>     pub fn get(&self) -> T;
>>>
>>> or maybe rename:
>>>
>>>     pub fn copy(&self) -> T;
>>>
>>> Then we are fine safety wise for now, right? It is even sensible for
>>> these `T: Copy` types.
>>
>> That is better than getting a reference, but still someone could read at
>> the same time that a write is happening (though we need some new
>> abstractions AFAIK?). But I fear that we forget about this issue,
>> because it'll be some time until we land parameters that are `!Copy` (if
>> at all...)
>
> No, that could not happen when we are not allowing custom parsing or
> sysfs access. Regarding forgetting, I already added a `NOTE` on `!Copy`,
> and I would add one on this issue as well.

Ultimately this is something for Miguel to decide. I would support an
unsafe accessor (we should also make it `-> T`), since there it "can't
go wrong", any UB is the fault of the user of the API. It also serves as
a good reminder, since a `NOTE` comment shouldn't be something
guaranteeing safety (we do have some of these global invariants, but I
feel like this one is too tribal and doesn't usually come up, so I feel
like it's more dangerous).

I think we should also move this patchset along, we could also opt for
no accessor at all :) Then it isn't really useful without the downstream
accessor function, but that can come after.

---
Cheers,
Benno