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: <ebfacf87-ce3a-49a0-90b3-74574eca0cec@gmx.de>
Date: Sun, 28 Dec 2025 22:02:05 +0100
From: Armin Wolf <W_Armin@....de>
To: Gladyshev Ilya <foxido@...ido.dev>
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

Am 25.12.25 um 21:37 schrieb Gladyshev Ilya:

> 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 :)

Nice, then i suggest you always set .no_notify_data and pass the event data inside said Optional.

Thanks,
Armin Wolf