linux-kernel - Re: [PATCH v2 02/16] thunderbolt: Don't pass a bitfield to FIELD

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: <20251213221420.10901610@pumpkin>
Date: Sat, 13 Dec 2025 22:14:20 +0000
From: David Laight <david.laight.linux@...il.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>,
 linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org, Geert Uytterhoeven
 <geert+renesas@...der.be>, Alexandre Belloni
 <alexandre.belloni@...tlin.com>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, Crt Mori <cmo@...exis.com>, Richard Genoud
 <richard.genoud@...tlin.com>, Andy Shevchenko
 <andriy.shevchenko@...el.com>, Luo Jie <quic_luoj@...cinc.com>, Peter
 Zijlstra <peterz@...radead.org>, Jakub Kicinski <kuba@...nel.org>,
 netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>, Mika
 Westerberg <mika.westerberg@...ux.intel.com>, Andreas Noever
 <andreas.noever@...il.com>, Yehezkel Bernat <YehezkelShB@...il.com>,
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: Re: [PATCH v2 02/16] thunderbolt: Don't pass a bitfield to
 FIELD_GET

On Sat, 13 Dec 2025 10:01:36 +0000
David Laight <david.laight.linux@...il.com> wrote:

> On Fri, 12 Dec 2025 21:28:31 -0500
> Yury Norov <yury.norov@...il.com> wrote:
> 
> > On Fri, Dec 12, 2025 at 07:37:07PM +0000, david.laight.linux@...il.com wrote:  
> > > From: David Laight <david.laight.linux@...il.com>
> > > 
> > > None of sizeof(), typeof() or __auto_type can be used with bitfields
> > > which makes it difficult to assign a #define parameter to a local
> > > without promoting char and short to int.
> > > 
> > > Change:
> > > 	u32 thunderbolt_version:8;
> > > to the equivalent:
> > > 	u8 thunderbolt_version;
> > > (and the other three bytes of 'DWORD 4' to match).
> > > 
> > > This is necessary so that FIELD_GET can use sizeof() to verify 'reg'.
> > > 
> > > Signed-off-by: David Laight <david.laight.linux@...il.com>
> > > ---
> > > 
> > > Changes for v2:
> > > - Change structure definition instead of call to FIELD_GET().
> > > 
> > > FIELD_GET currently uses _Generic() which behaves differently for
> > > gcc and clang (I suspect both are wrong!).
> > > gcc treats 'u32 foo:8' as 'u8', but will take the 'default' for other
> > > widths (which will generate an error in FIED_GET().
> > > clang treats 'u32 foo:n' as 'u32'.    
> > 
> > FIELD_GET() works just well with bitfields, and whatever you do breaks
> > it. I pointed that in v1, but instead of fixing it, you do really well
> > hiding the problem.  
> 
> It doesn't, pass 'u32 foo:6' when using gcc.

I've been trying to look up how _Generic() should behave for bitfields.
Basically it doesn't seem to be specified in the C standard.
Pretty much all you can do is force an integer promotion - and that only
works if the size is <= 32.
(I really hope there aren't any bigger bitfields lurking...)
But FIELD_GET() wants to check that 'reg' is 'big enough' to hold 'mask'.
An integer promotion breaks that for char/short.

I did try erroring on statically_true(mask > reg), but that throws up
a lot of false positives (even for non-constant 'reg').
It really is amazing that you get FIELD_GET(GENMASK(7, 0), val) instead
of 'val & 0xff' (and I don't mean code that want the low 8 bits of some
device register that is made up of lots of fields).

FIELD_PREP() does support bitfields (for 'val'), they get an integer
promotion applied.

There seems to be exactly one instance of 'reg' being a bitfield,
bloating all the other expansions for a trivially changeable line of
code is just stupid.

	David

> 
> 	David
> 
> > 
> > I see no reasons to hack a random victim because of your rework. So
> > NAK for this. 
> > 
> > In v3, please add an explicit test to make sure that bitfields are not
> > broken with new implementation.
> > 
> > Thanks,
> > Yury  
>