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] [day] [month] [year] [list]

Message-ID: <20250614151844.50524610@jic23-huawei>
Date: Sat, 14 Jun 2025 15:18:44 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Nicolas Frattaroli
 <nicolas.frattaroli@...labora.com>, David Lechner <dlechner@...libre.com>,
 linux-rockchip@...ts.infradead.org, Michael Hennerich
 <michael.hennerich@...log.com>, Lars-Peter Clausen <lars@...afoo.de>, 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
Subject: Re: [PATCH 00/28] iio: zero init stack with { } instead of memset()

On Sat, 14 Jun 2025 13:18:44 +0100
Jonathan Cameron <jic23@...nel.org> wrote:

> On Sat, 14 Jun 2025 08:47:25 +0200
> Pavel Machek <pavel@....cz> wrote:
> 
> > On Thu 2025-06-12 22:10:07, Andy Shevchenko wrote:  
> > > On Thu, Jun 12, 2025 at 08:54:07PM +0200, Pavel Machek wrote:    
> > > > > 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    
> > > > 
> > > > Well... I'm pretty sure parts of this would make it into -stable as a
> > > > dependency, or because AUTOSEL decides it is a bugfix. So..
> > > > 
> > > > GNU C                  4.9              gcc --version
> > > > Clang/LLVM (optional)  10.0.1           clang --version    
> > > 
> > > Even though, what the kernel versions are you referring to? I am sure there
> > > plenty of cases with {} there.    
> > 
> > 5.10, for example. I'm sure they are, uninitialized padding is a
> > security hole, but rather hard to detect if they are not specifically
> > looking.  
> 
> The stack kunit test is there back to 5.0-rc4 
> 50ceaa95ea09 ("lib: Introduce test_stackinit module")
> 
> So I think we should be pretty well defended against issues.
> 
> Hence I plan to pick this up curently.
> 
> Thanks all for inputs on this.
> 
> Fun corners of the C spec vs implementations!
> 
> Jonathan
> 
I want to give this some testing exposure from 0-day etc in case
we missed any build related issues so I've queued it up on my testing branch.
I can still pick up tags / rebase etc for now.

Thanks,

Jonathan

> > 
> > BR,
> > 								Pavel  
> 
>