linux-kernel - Re: Very slow clang kernel config ..

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:   Wed, 5 May 2021 18:06:44 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Adrian Bunk <bunk@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tom Stellard <tstellar@...hat.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Fangrui Song <maskray@...gle.com>,
        Serge Guelton <sguelton@...hat.com>,
        Sylvestre Ledru <sylvestre@...illa.com>
Subject: Re: Very slow clang kernel config ..

On Wed, May 5, 2021 at 4:13 PM David Laight <David.Laight@...lab.com> wrote:
>
> Many years ago the company I worked for found that the unix 'utmpx'
> file was getting corrupted (due to incorrect locking).
> The functions had been places in an archive part of libc (for
> various reasons).
> Getting the fix onto the customers machine (we were the OS vendor)
> involved determining which applications from 3rd (4th?) parties
> had been linked with the broken code and then applying enough
> 'gentle persuasion' to get them to relink the offending programs.
> Even this can be problematic because the source control systems
> of some companies isn't great (it is probably better these days).
> But getting the 'previous version' rebuilt with a new libc.a
> can be very problematic.

If you are a library vendor and you provide the fixed library, then
you are done. It is your customer's call to rebuild their software or
not; and they are the ones choosing static linking or not.

Sure, you want to offer the best service to your clients, and some
customers will choose static linking without fully understanding the
pros/cons, but you cannot do anything against that. And you still need
to provide the static version for those clients that know they need
it.

> No because there are messages sent to system daemons and file
> formats that can be system dependant.
> Not everything is a system call.

That is orthogonal to static linking or not, which was the topic at hand.

What you are talking about now are dependencies on external entities
and services. Static linking is not better nor worse just because you
depend on a local process, a file, a networked service, a particular
piece of hardware being present, etc.

> Remind be to request our management to let me remove all the C++
> from most of our programs.

Yeah, the problem exists since before 1998 :)

A stable, common C++ ABI etc. would have had some advantages, but it
did not happen.

> None of them actually need it, the reasons for C++ aren't technical.

Well, no program "needs" any particular language, but there are
advantages and disadvantages of using languages with more features
(and more complexity, too). It is a balance.

For the kernel, we believe Rust brings enough advantages over *both* C
and C++ to merit using it. C++ also has advantages over C, but it has
a big complexity burden, it has not had the luxury of being designed
from scratch with decades of hindsight from C and C++ like Rust has
had, and it does not have a UB-free subset.

> That sounds like it has all the same problems as pre-compiled headers.

PCHs are a hack to improve build times, yes.

In Rust, however, it is a more fundamental feature and the needed
information goes encoded into your library (.rlib, .so...).

Cheers,
Miguel