linux-kernel - Re: [PATCH v3 0/4] rust: extend `module!` macro with integer parameter support

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: <Z2IwkAxgMt2XqI9U@localhost>
Date: Tue, 17 Dec 2024 18:16:48 -0800
From: Josh Triplett <josh@...htriplett.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Jens Axboe <axboe@...nel.dk>, Greg KH <gregkh@...uxfoundation.org>,
	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>,
	Benno Lossin <benno.lossin@...ton.me>,
	Alice Ryhl <aliceryhl@...gle.com>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>,
	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
Subject: Re: [PATCH v3 0/4] rust: extend `module!` macro with integer
 parameter support

On Mon, Dec 16, 2024 at 04:48:21PM +0100, Miguel Ojeda wrote:
> On Mon, Dec 16, 2024 at 4:39 PM Miguel Ojeda
> <miguel.ojeda.sandonis@...il.com> wrote:
> >
> > Agreed. I would suggest to consider marking it as a Rust reference
> > driver, since it is a prime candidate for it:
> >
> >     https://rust-for-linux.com/rust-reference-drivers
> >
> > That way, it is clearer that the duplication is meant to build the
> > abstractions and temporary in the long-term.
> >
> > Then we can also easily track which ones are meant to be those, and
> > Greg can get justifiably angry at you/us if the duplication isn't
> > resolved when the right time comes... :)
> 
> By the way, I half-jokingly suggested this elsewhere, but we could
> trivially allow module parameters only for particular modules, i.e.
> only allow to use the `params` key here if the name matches `rnull`
> (or if they set a special flag or whatever).
> 
> Yes, it is a hack, but it would give people pause when trying to use
> the feature, i.e. to think twice. And, to me, it makes sense to
> encode/acknowledge this kind of thing explicitly anyway.
> 
> So if that would unblock this and reduce the chance of repeating
> mistakes of the past, then we can easily do that too.

This seems like a great idea. An allowlist of drivers that are allowed
to use module parameters would encourage *new* drivers to not use them,
and that allowlist can have a comment atop it saying "Only add your
driver to this list if it needs to maintain an interface compatible with
an existing driver in order to avoid breaking userspace. Otherwise, use
configfs, sysfs, debugfs, or something else other than module
parameters."

I wonder if we can implement such an allowlist for C modules, too. :)