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: <CANiq72kFUSFgBv7Es3Mhe4HUaSPZk0EVW=JaMdaAGHsQOxYN6w@mail.gmail.com>
Date: Tue, 1 Jul 2025 18:27:21 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Benno Lossin <lossin@...nel.org>
Cc: Andreas Hindborg <a.hindborg@...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

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.

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.

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 {}`).

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ