linux-kernel - Re: C aggregate passing (Rust kernel policy)

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: <CAHk-=whZwXK9shqeV5fpRF9CRqApVy5wz6myNeAkyuFm-ERTpQ@mail.gmail.com>
Date: Fri, 21 Feb 2025 12:26:02 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jan Engelhardt <ej@...i.de>
Cc: David Laight <david.laight.linux@...il.com>, "H. Peter Anvin" <hpa@...or.com>, 
	Greg KH <gregkh@...uxfoundation.org>, Boqun Feng <boqun.feng@...il.com>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Christoph Hellwig <hch@...radead.org>, 
	rust-for-linux <rust-for-linux@...r.kernel.org>, David Airlie <airlied@...il.com>, 
	linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: C aggregate passing (Rust kernel policy)

On Fri, 21 Feb 2025 at 12:06, Jan Engelhardt <ej@...i.de> wrote:
>
> >(Apart from the fact that c++ makes it hard to ensure all the non-class
> >members are initialised.)
>
>         struct stat x{};
>         struct stat x = {};
>
> all of x's members (which are scalar and thus non-class) are
> initialized. The second line even works in C.

Sadly, it doesn't work very reliably.

Yes, if it's the empty initializer, the C standard afaik requires that
it clear everything.

But if you make the mistake of thinking that you want to initialize
one field to anything but zero, and instead do the initializer like
this:

    struct stat x = { .field = 7 };

suddenly padding and various union members can be left uninitialized.

Gcc used to initialize it all, but as of gcc-15 it apparently says
"Oh, the standard allows this crazy behavior, so we'll do it by
default".

Yeah. People love to talk about "safe C", but compiler people have
actively tried to make C unsafer for decades. The C standards
committee has been complicit. I've ranted about the crazy C alias
rules before.

We (now) avoid this particular pitfall in the kernel with

    -fzero-init-padding-bits=all

but outside of the kernel you may need to look out for this very
subtle odd rule.

             Linus