linux-kernel - Re: [RFC PATCH 2/3] rust: introduce WMI abstractions

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: <d8033c40-9cac-4827-9d8a-5cb3d727ec5b@foxido.dev>
Date: Thu, 25 Dec 2025 23:37:05 +0300
From: Gladyshev Ilya <foxido@...ido.dev>
To: Armin Wolf <W_Armin@....de>
Cc: Len Brown <lenb@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 Danilo Krummrich <dakr@...nel.org>, Tamir Duberstein <tamird@...il.com>,
 platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [RFC PATCH 2/3] rust: introduce WMI abstractions

On 12/25/25 21:06, Armin Wolf wrote:
>> +// SAFETY: A call to `unregister` for a given instance of `RegType` 
>> is guaranteed to be valid if
>> +// a preceding call to `register` has been successful.
>> +unsafe impl<T: Driver + 'static> driver::RegistrationOps for 
>> Adapter<T> {
>> +    type RegType = bindings::wmi_driver;
>> +
>> +    unsafe fn register(
>> +        wdrv: &Opaque<Self::RegType>,
>> +        name: &'static CStr,
>> +        module: &'static ThisModule,
>> +    ) -> Result {
>> +        macro_rules! map_callback {
>> +            ($flag:ident -> $callback:ident) => {
>> +                if T::$flag {
>> +                    Some(Self::$callback)
>> +                } else {
>> +                    None
>> +                }
>> +            };
>> +        }
>> +
>> +        // SAFETY: It's safe to set the fields of `struct wmi_driver` 
>> on initialization.
>> +        unsafe {
>> +            (*wdrv.get()).driver.name = name.as_char_ptr();
>> +            (*wdrv.get()).driver.probe_type = 
>> bindings::probe_type_PROBE_PREFER_ASYNCHRONOUS;
>> +            (*wdrv.get()).id_table = T::TABLE.as_ptr();
>> +            (*wdrv.get()).probe = map_callback!(HAS_PROBE -> 
>> probe_callback);
>> +            (*wdrv.get()).notify = map_callback!(HAS_NOTIFY -> 
>> notify_callback);
> 
> I think it should be possible to handle WMI drivers 
> requiring .no_notify_data to be set. Is there
> a way to declare the WMI event data passed to the notify() callback as 
> optional? If yes, then i suggest
> that we always set .no_notify_data and simply require the WMI drivers 
> themselves to verify that a given
> WMI event does contain additional event data.

Yes, I can change the notify API to receive Optional<&AcpiBuffer> 
instead of &AcpiBuffer, so every driver will be forced to verify payload 
existence by Rust's type system.

IIRC, casting raw (C) pointer to Optional<&T> is actually a no-op in 
Rust, since NULL is automatically mapped to None (empty Optional), so it 
will be a zero-cost typesystem win :)