linux-kernel - Re: [PATCH v11 2/3] rust: add parameter support to the `module!` macro

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: <87wmauot0b.fsf@kernel.org>
Date: Tue, 06 May 2025 13:53:08 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
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>,  "Benno
 Lossin" <benno.lossin@...ton.me>,  "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 v11 2/3] rust: add parameter support to the `module!` macro

"Alice Ryhl" <aliceryhl@...gle.com> writes:

> On Mon, May 05, 2025 at 11:55:33AM +0200, Andreas Hindborg wrote:
>> "Alice Ryhl" <aliceryhl@...gle.com> writes:
>>
>> > On Fri, May 02, 2025 at 02:16:35PM +0200, Andreas Hindborg wrote:
>> > It would be a use-after-free to
>> > access it during module teardown. For example, what if I access this
>> > static during its own destructor? Or during the destructor of another
>> > module parameter?
>>
>> Yes, that is a problem.
>>
>> We can get around it for now by just not calling `free` for now. We only
>> support simple types that do not need drop. I think we would have to
>> seal the `ModuleParam` trait for this.
>>
>> For a proper solution, we could
>>  - Require a token to read the parameter.
>>  - Synchronize on a module private field and return an option from the
>>    parameter getter. This would require module exit to run before param
>>    free. I think this is the case, but I did not check.
>>  - Use a `Revocable` and revoke the parameter in `free`.
>>
>> Any other ideas or comments on the outlined solutions?
>
> I think the simplest you can do right now is
>
> trait ModuleParam: Copy

Cool 👍

>
> so that it can't contain any non-trivial values. That way you don't need
> Drop either.
>
> Long term, I think we need a way to detect whether it's safe to access
> module globals. The exact same problem applies to the existing global
> for the module itself - except it's worse there because we can't access
> that one during init either.

Yep.



Best regards,
Andreas Hindborg