Re: [PATCH v2] kbuild: Re-enable -Wunterminated-string-initialization

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Kees Cook <kees@kernel.org>
Date: Wed, 6 Aug 2025 12:05:32 -0700

> On Wed, Aug 06, 2025 at 05:29:55PM +0200, Alexander Lobakin wrote:
>> From: Nathan Chancellor <nathan@kernel.org>
> 
> Thank you for the fixes Nathan! I'll dig through these and get them sent
> out before I try to land this patch again -- "But COMPILE_TEST is never
> wrong!" ;)
> 
>>> [...]
>>> descriptions expected to be stable once they are released or are we able
>>
>> Ethtool private stats are not "ABI" at all. Moreover, if they result in
>> incorrect code, this needs to be fixed no matter if someone already
>> wrote scripts dependent on these names or not.
> 
> Internally there isn't an ABI, but the userspace interface effectively has
> an ABI: the strings are fixed-size and NUL-padded but not NUL-terminated.

Ooops, maybe I missed something. I mean I know that Ethtool passes one
big array of 32-byte-sized strings, but is it fine if some of these
strings won't be NUL-terminated?

> 
>>> to adjust them? We could maybe shave an 'o' from 'unknown' to easily
>>> resolve this without losing much in the way of quick visual processing.
>>
>> I've no idea why it's popular to define Ethtool stats names in drivers
>> using a fixed array of ETH_GSTRING_LEN and then do memcpy().
> 
> The above is why: they are fixed-size, non-NUL-terminated strings, so
> many drivers use this memcpy pattern. But not all.

Sure, lots of drivers uses normal string copy functions etc.
But Ethtool strings *must* be NUL-terminated, so this fixed-size +
memcpy() only hurts.

> 
>> I've been always using just `const char * const[]` + strscpy() (then
>> switched the latter to ethtool_puts()/ethtool_sprintf() -- we even have
>> special helpers for that). In case some name goes past ETH_GSTRING_LEN,
>> it would just be truncated, but always have \0 at the end.
> 
> Unfortunately this is not true: not all sources are NUL terminated.

I meant the following:

Imagine a driver defining its stats string:

static const char * const arr[] = {
	...
	"some_stat_that_goes_above_ETH_GSTRING_LEN",
};

Then, if this driver copies that string using ethtool_puts() or just
strscpy(ETH_GSTRING_LEN), the string will be truncated, but \0 at the
end is guaranteed.

> 
>> Plus most of the names are shorter than 32, so defining such arrays of
>> 32 just wastes space in .rodata.
> 
> That IS true, but many drivers just keep giant blocks of data they can
> memcpy. :(
> 
> Regardless, I will double-check this and see what needs to happen here.
> I've fixed a lot of these already[1].
> 
> -Kees
> 
> [1] https://lore.kernel.org/lkml/20250416010210.work.904-kees@kernel.org/

Thanks,
Olek