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]

Date:   Mon, 6 Sep 2021 22:14:32 +0200
From:   Jakub Jelinek <jakub@...hat.com>
To:     Segher Boessenkool <segher@...nel.crashing.org>
Cc:     Florian Weimer <fweimer@...hat.com>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        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 Mon, Sep 06, 2021 at 02:48:08PM -0500, Segher Boessenkool wrote:
> > This is an exaggeration.  On several architectures, the kernel cannot
> > use the vector built-ins directly.  Some of the implementing headers are
> > very special and intertwined with the compiler.  <stdarg.h> is currently
> > not such a case, but it's just not technically not feasible to avoid
> > dependencies on all compiler headers.  I think this considerably weakens
> > the case against <stdarg.h> because the compiler version is so obviously
> > harmless.
> 
> Exactly Florian.  Thank you for so clearly making the point.

Yes.  While stdarg.h builtins haven't changed for a while (we had some since
~ 1999, changed them incompatibly in 2000 and again in 2002 and not since then
and I'm not aware of plans to change them in the near future), e.g. for the
backend intrinsics, we change some every year or two, the only guaranteed APIs are
those provided by the headers (x86intrin.h/*mmintrin.h etc. on x86,
arm_{neon,sve}.h etc. on arm*, ...) and the underlying builtins are
sometimes removed, further ones added, etc.
stdarg.h is also such a header, although admittedly much simpler and less
likely to change.

I must say I don't understand the argument about uninstalled compilers,
uninstalled compilers work just fine if one supplies the right include path
for them, for C it is trivial and apparently the kernel has been already
doing that through -nostdinc -isystem .../include, for C++ a little bit
harder but we have a script for that.

	Jakub