linux-kernel - Re: [PATCH 2/3] rust: implement wrapper for acpi

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: <CANiq72=TAXwjjxFiKiiwh9m_rRK_yUVS4b+2st=QJWErz5qTpQ@mail.gmail.com>
Date: Thu, 8 Jan 2026 19:46:45 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Gladyshev Ilya <foxido@...ido.dev>
Cc: Gary Guo <gary@...yguo.net>, 
	"foxido @ foxido . dev-cc= Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, 
	Boqun Feng <boqun.feng@...il.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>, 
	Armin Wolf <W_Armin@....de>, platform-driver-x86@...r.kernel.org, 
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, 
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 2/3] rust: implement wrapper for acpi_object

On Thu, Jan 8, 2026 at 6:11 PM Gladyshev Ilya <foxido@...ido.dev> wrote:
>
> Hm, I looked through ACPI_FREE() call sites and acpi_evaluate_object()
> implementation, and it seems to me that the acpi_object's lifetime is
> the same as its internal buffer. Overall, it is indeed managed
> externally, but acpi_object and acpi_object::buffer->pointer live
> together. I’m not an ACPI expert, though, so maybe I’m missing something.
>
> Anyway, the current Rust setup seems fine for now:
> 0. AcpiObject validity is guaranteed by whoever constructed/passed it (C
> side for WMI abstractions, for example)
> 1. You can only convert &AcpiObject to &AcpiSubType (reference to
> reference), so AcpiSubType can't outlive AcpiObject
> 2. You can't steal the data pointer from &AcpiSubType either, because
> the Deref impl is "logically safe" and only gives you a reference to the
> inner data, which can't outlive AcpiSubType's reference -> can't outlive
> AcpiObject.
>
> So for now until AcpiObject lives _less_ than it's inner data,
> everything is OK.

Assuming this is correct, this sort of analysis is typically nice to
keep documented as as an implementation comment (`//`) somewhere
(instead of just in the mailing list or the commit message) -- would
that make sense?

> Using an enum would require keeping Rust's enum synced with the C side,
> as well as implementing some simple but non-trivial checks that the
> `type_` field is a valid enum value (and the valid range isn't
> continuous). I think that keeping it as an integer is simpler and better
> matches C side.

If this refers to the `ACPI_TYPE_*` constants, there seems to be a
comment in the C docs that requires it to be kept in sync already with
elsewhere, so perhaps it could be reasonable to add one more place to
sync? (Though I don't see the mentioned arrays from a quick grep?)

     * NOTE: Types must be kept in sync with the global acpi_ns_properties
     * and acpi_ns_type_names arrays.

Ideally, these would be actual `enum`s on the C side and then
eventually we should be able to have `bindgen` generate the new kind
of `enum` that keeps this in sync and generates those checks for us,
see my suggestion at:

    Support a new "enum variant" kind, similar to `rustified_enum`, that
    provides a safe method to transform a C `enum` to Rust.
    https://github.com/Rust-for-Linux/linux/issues/353

(But we can't do it just know, and even if it lands in `bindgen` we
will probably need to wait to bump the minimum etc.)

Cheers,
Miguel