linux-kernel - Re: [RFC PATCH] Revert "um: Make CONFIG_STATIC

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:   Tue, 30 Jun 2020 15:47:15 -0700
From:   Brendan Higgins <brendanhiggins@...gle.com>
To:     Ignat Korchagin <ignat@...udflare.com>
Cc:     Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        linux-um <linux-um@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] Revert "um: Make CONFIG_STATIC_LINK actually static"

On Wed, Jun 24, 2020 at 2:23 PM Ignat Korchagin <ignat@...udflare.com> wrote:
>
> This reverts commit 3363179385629c1804ea846f4e72608c2201a81e.
>
> This change is too restrictive. I've been running UML statically linked kernel
>  with UML_NET_VECTOR networking in a docker "FROM: scratch" container just fine.
> As long as we don't reference network peers by hostname and use only IP
> addresses, NSS is not needed, so not used. In other words, it is possible to
> have statically linked UML and UML_NET_VECTOR (and other networking types) and
> use it, although with some restrictions, so let's not disable it.
>
> Additionally, it should be at least theoretically possible to use another libc
> (like musl, bionic etc) for static linking. I was able with some hacks to
> compile UML against musl, although the executable segfaults for now. But this
> option prevents even the research to be done.

The reason that we removed support for static linking when these
networking options are enabled is because gcc doesn't support loading
NSS when statically linked, which consequently breaks allyesconfig for
UML under gcc. That is still the case with your revert.

I fully support the goal behind what you are trying to do. However, I
do not want to see this patch accepted unless it is accompanied by an
alternative change that still allows UML to compile under
allyesconfig.

You said that in the current state, researching a solution is
possible? Can you not research a solution with your patch applied to
your own branch?

Cheers