linux-kernel - Re: [PATCH v3 5/5] rust: Add KUNIT tests for bitfield

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: <20250919230227.GA1901670@joelbox2>
Date: Fri, 19 Sep 2025 19:02:27 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Yury Norov <yury.norov@...il.com>, acourbot@...dia.com
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	dakr@...nel.org, Alistair Popple <apopple@...dia.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	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>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	John Hubbard <jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
	joel@...lfernandes.org, Elle Rhumsaa <elle@...thered-steel.dev>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v3 5/5] rust: Add KUNIT tests for bitfield

On Tue, Sep 16, 2025 at 05:59:18AM -0400, Joel Fernandes wrote:
[...]
> > > > The same question for the setters. What would happen for this:
> > > > 
> > > >     let bf = bf::default()
> > > >              .set_state(0xf)
> > > >              .set_ready(true);
> > > > 
> > > > I think that after the first out-of-boundary in set_state(), you
> > > > should abort the call chain, make sure you're not touching memory
> > > > in set_ready() and returning some type of error.
> > > 
> > > Here, on out of boundary, we just ignore the extra bits passed to
> > > set_state. I think it would be odd if we errored out honestly. We are
> > > using 'as u8' in the struct so we would accept any u8 as input, but
> > > then if we complained that extra bits were sent, that would be odd.
> > 
> > That really depends on your purpose. If your end goal is the safest API
> > in the world, and you're ready to sacrifice some performance (which is
> > exactly opposite to the C case), then you'd return to your user with a
> > simple question: are you sure you can fit this 8-bit number into a 3-bit
> > storage?   
> 
> I think personally I am OK with rejecting requests about this, so we can
> agree on this.

It is not possible to reject values passed to set, because it returns Self
and follows the builder-pattern, to do this we will need to return Result,
and have the caller unwrap it, and have to rename it to try_set().

Instead of that, I would just extract the bits from the value the user passed
and ignore the rest (example if 0xff is passed for a 4-bit bitfield, then the
field is 0xf.)

Alex what do you think, should set_ be fallible?

thanks,

 - Joel