linux-kernel - Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

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: <20210904191531.GS1583@gate.crashing.org>
Date:   Sat, 4 Sep 2021 14:15:31 -0500
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Linus Torvalds <torvalds@...uxfoundation.org>
Cc:     Florian Weimer <fweimer@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        llvm@...ts.linux.dev, linux-toolchains@...r.kernel.org
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

On Sat, Sep 04, 2021 at 10:22:25AM -0700, Linus Torvalds wrote:
> On Sat, Sep 4, 2021 at 8:19 AM Florian Weimer <fweimer@...hat.com> wrote:
> > In any case, it would be nice to know what the real motivation is.
> 
> I don't know about the original motivation, but the reason I like that
> patch after-the-fact is that I've actually been in situations where I
> test out self-built compilers without installing them.

Then you probably know that that is quite hard to do correctly.  And
installing the compiler (into a temporary dir that you can just blow
away after you are done with it) is trivial (see for example
<https://gcc.gnu.org/install/finalinstall.html> line 11 or so).

Also, the standard headers are *part of* the compiler.  Including those
(like <stdarg.h> here) that are required for freestanding
implementations.

> Then it's convenient to have a completely standalone kernel tree.

Yes, and you certainly do not want to mix in anything userspace,
accidentally or not.  But these "freestanding" headers already have to
make sure they do not do that, and they are used by many OSes and
embedded-style things, so you can have some confidence that this
actually works.

And the C standard requires you to use these headers to use some
features of the C language (variable arguments in this specific case).
You can of course mimic whatever some implementation does and hope that
will work on some other implementations, and on future versions of that
first implementation as well.  But that is imo not a good idea, just
using the standard headers (which are required, and are there on all
implementations I have heard of, without bugs) is a much simpler idea,
much more future-proof, much less maintenance.

> Nobody cares about things like <stdatomic.h> They are completely
> irrelevant for the kernel, exactly because we've always just done our
> own, or used __builtin_xyz() for things.

The Linux kernel needs (or wants) stronger primitives than provided
there, yeah, so you could not even use it as the underlying
implementation for the semantics the kernel wants (which it could do
with <stdint.h> to implement u64 etc.)

> <stdarg.h> is the only actual core header file that we have always
> taken from the installed system headers - because historically it
> really was required. Everything else we can just do ourselves.

You also need <stdint.h> and <stddef.h>.  These are much simpler to
implement of course, but see for example the c46bbf5d2def commit I
mentioned before.  Some of these compiler headers might have been buggy
(or non-existent) historically, but that is very long ago, you really
can expect at least C99 to be there (and work correctly) nowadays :-)

Segher