linux-kernel - Re: [PATCH v4 1/4] rust: macros: add derive macro for `Into`

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: <DFTXZ7AN65B2.ZW0EK0VZFYT5@gmail.com>
Date: Wed, 21 Jan 2026 12:20:20 +0900
From: "Jesung Yang" <y.j3ms.n@...il.com>
To: "Benno Lossin" <lossin@...nel.org>, "Jesung Yang" <y.j3ms.n@...il.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>,
 "Gary Guo" <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Andreas Hindborg" <a.hindborg@...nel.org>,
 "Alice Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
 "Danilo Krummrich" <dakr@...nel.org>, "Alexandre Courbot"
 <acourbot@...dia.com>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v4 1/4] rust: macros: add derive macro for `Into`

OK, let me reignite this series...

On Tue Dec 30, 2025 at 6:09 PM KST, Benno Lossin wrote:
> On Mon Dec 29, 2025 at 1:29 PM CET, Jesung Yang wrote:
>> On Sat, Dec 27, 2025 at 1:57 PM Benno Lossin <lossin@...nel.org> wrote:
[...]
>> To sum up, I see three options:
>>
>>     1. Drop support for `#[repr(C)]` enums entirely.
>>     2. Special-case `#[repr(C)]` enums: allow them to default to
>>        `isize`, otherwise require `#[repr({integer})]`.
>>     3. Permit missing `#[repr({integer})]` generally.
>>
>> I am personally leaning toward Option 3, since our existing
>> compile-time check provides a sufficient safety margin to allow this
>> flexibility.
>>
>> Thoughts on these?
>
> Looking at the nomicon documentation [1] again, I found the following:
>
>     repr(C) is equivalent to one of repr(u*) (see the next section) for
>     fieldless enums. The chosen size and sign is the default enum size
>     and sign for the target platform's C application binary interface
>     (ABI). Note that enum representation in C is implementation defined,
>     so this is really a "best guess". In particular, this may be
>     incorrect when the C code of interest is compiled with certain
>     flags.
>
> Which to me reads as "don't use `repr(C)`, if you want to know which
> repr the enum gets". Especially the last part is concerning to me, as
> the kernel uses lots of (bespoke) compiler flags. So I'm thinking we
> should just drop `repr(C)` enum support. Any thoughts from others?
>
> [1]: https://doc.rust-lang.org/nomicon/other-reprs.html

I think the last part you mentioned is less of a concern in this
context, as this series does not introduce new FFI boundaries;
`try_from` and `into` themselves live only on the Rust side and do not
interact with the C side. We are indeed relying on Rust's "best guess"
about the internal representation to perform compile-time checks, but
these trait implementations do not pass enums across the boundary to C
code.

Your concern is certainly valid for anyone introducing new `#[repr(C)]`
fieldless enums that interface with the C side (and we may want to
revisit any existing ones). In our case, however, it should be safe as we
ensure that discriminants do not overflow Rust's own internal
representation of `#[repr(C)]` enums.

Best regards,
Jesung