linux-kernel - Re: [PATCH 00/28] iio: zero init stack with { } instead of memset()

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: <CAHp75VdVB1OogZay+FDYVY0XajxcOx6t8T8LJSs+zSZg8TkaDQ@mail.gmail.com>
Date: Thu, 12 Jun 2025 15:28:37 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: David Lechner <dlechner@...libre.com>, linux-rockchip@...ts.infradead.org, 
	Michael Hennerich <michael.hennerich@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, 
	Jonathan Cameron <jic23@...nel.org>, Nuno Sá <nuno.sa@...log.com>, 
	Andy Shevchenko <andy@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Heiko Stuebner <heiko@...ech.de>, 
	Maxime Coquelin <mcoquelin.stm32@...il.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, 
	Francesco Dolcini <francesco@...cini.it>, 
	João Paulo Gonçalves <jpaulo.silvagoncalves@...il.com>, 
	Leonard Göhrs <l.goehrs@...gutronix.de>, 
	kernel@...gutronix.de, Oleksij Rempel <o.rempel@...gutronix.de>, 
	Roan van Dijk <roan@...tonic.nl>, Tomasz Duszynski <tomasz.duszynski@...akon.com>, 
	Jacopo Mondi <jacopo@...ndi.org>, Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@....com>, 
	Mudit Sharma <muditsharma.info@...il.com>, 
	Javier Carrasco <javier.carrasco.cruz@...il.com>, Ondřej Jirman <megi@....cz>, 
	Andreas Klinger <ak@...klinger.de>, Petre Rodan <petre.rodan@...dimension.ro>, 
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org, 
	linux-stm32@...md-mailman.stormreply.com, Pavel Machek <pavel@....cz>
Subject: Re: [PATCH 00/28] iio: zero init stack with { } instead of memset()

On Thu, Jun 12, 2025 at 3:12 PM Nicolas Frattaroli
<nicolas.frattaroli@...labora.com> wrote:

> I thought I'd chime in as someone uninvolved because this seemed
> interesting.

Welcome! Other opinions on such a topic are always appreciated.

> On Thursday, 12 June 2025 11:17:52 Central European Summer Time Pavel Machek wrote:
> >
> > > Jonathan mentioned recently that he would like to get away from using
> > > memset() to zero-initialize stack memory in the IIO subsystem. And we
> > > have it on good authority that initializing a struct or array with = { }
> > > is the preferred way to do this in the kernel [1]. So here is a series
> > > to take care of that.
> >
> > 1) Is it worth the churn?
> >
> > 2) Will this fail to initialize padding with some obscure compiler?
>
> as of right now, the only two C compilers that are supported are
> GCC >= 8.1, and Clang >= 13.0.1. If anyone even manages to get the kernel
> to finish a build with something else, I think the compiler not
> implementing the C standard correctly is the least of their worries.
>
> My bigger worry is that = { } is only guaranteed to be as correct as
> memset on C23, and the kernel's standard right now is C11. For that
> reason alone, I don't think memset should be moved away from for now,
> unless someone can verify that every GCC release >= 8.1 and every
> Clang release >= 13.0.1 does the right thing here regardless.
>
> >
> > 3) Why do you believe that {} is the preffered way? All we have is
> > Kees' email that explains that = {} maybe works in configs he tested.
>
> = { } is guaranteed to work in C23, as per the standard, but again we're
> not on C23.
>
> The reason to prefer this is likely that it's easier for static analysis
> to see the struct as initialised, but that's me making assumptions here.
>
> A more human-centric argument is that once we're on a C standards version
> where = { } is guaranteed to be correct, then = { } is much more obviously
> correct to a reader than a memset with a value and a size somewhere later
> in the code. This argument is evident from the number of patches in this
> series where the memset and the declaration are not in the same hunk.
> That's the kind of stuff that keeps me awake at night, sweating profusely.

While all you said seems true and I agree with, the pedantism here is
not needed as in the Linux kernel we have {} used for ages in tons of
code and if something went wrong with that we should have had bug
reports already. Are you aware of such? Personally I haven't heard
even one related to this. But if you know, I am really more than
interested to read about (please, give pointers to such a discussion).

-- 
With Best Regards,
Andy Shevchenko