linux-kernel - Re: [PATCH 1/2] nova-core: Add a library for bitfields in Rust structs

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: <B7EF7192-9228-4B9E-B029-3E51E6765016@nvidia.com>
Date: Thu, 4 Sep 2025 11:32:28 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Danilo
 Krummrich <dakr@...nel.org>, David Airlie <airlied@...il.com>, Simona Vetter
	<simona@...ll.ch>, 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 <lossin@...nel.org>, Andreas
 Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Trevor
 Gross <tmgross@...ch.edu>, John Hubbard <jhubbard@...dia.com>, Alistair
 Popple <apopple@...dia.com>, "nouveau@...ts.freedesktop.org"
	<nouveau@...ts.freedesktop.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH 1/2] nova-core: Add a library for bitfields in Rust
 structs



> On Sep 3, 2025, at 11:16 PM, Alexandre Courbot <acourbot@...dia.com> wrote:
> 
> On Thu Sep 4, 2025 at 12:15 AM JST, Joel Fernandes wrote:
> <snip>
>>>> +use kernel::prelude::*;
>>>> +
>>>> +/// Macro for defining bitfield-packed structures in Rust.
>>>> +/// The size of the underlying storage type is specified with #[repr(TYPE)].
>>>> +///
>>>> +/// # Example (just for illustration)
>>>> +/// ```rust
>>>> +/// bitstruct! {
>>>> +///     #[repr(u64)]
>>>> +///     pub struct PageTableEntry {
>>>> +///         0:0       present     as bool,
>>>> +///         1:1       writable    as bool,
>>>> +///         11:9      available   as u8,
>>>> +///         51:12     pfn         as u64,
>>>> +///         62:52     available2  as u16,
>>>> +///         63:63     nx          as bool,
>>> 
>>> A note on syntax: for nova-core, we may want to use the `H:L` notation,
>>> as this is what OpenRM uses, but in the larger kernel we might want to
>>> use inclusive ranges (`L..=H`) as it will look more natural in Rust
>>> code (and is the notation the `bits` module already uses).
>> 
>> Perhaps future add-on enhancement to have both syntax? I'd like to initially
>> keep H:L and stabilize the code first, what do you think?
> 
> Let's have the discussion with the other stakeholders (Daniel?). I think
> in Nova we want to keep the `H:L` syntax, as it matches what the OpenRM
> headers do (so Nova would have its own `register` macro that calls into
> the common one, tweaking things as it needs). But in the kernel crate we
> should use something intuitive for everyone.

I do not think we should have a nova only register macro using an external
register macro. We should have just one outside-nova macro, and can
support both syntaxes with it if needed.

Though, to be honest, I am thinking only supporting H:L is more than
enough initially and others on the thread are also Ok with it.
We can always add support for the alternate syntax as well if needed, in the future.

Thanks.