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] [day] [month] [year] [list]

Date:   Wed, 1 Jul 2020 00:11:31 +0100
From:   Ignat Korchagin <ignat@...udflare.com>
To:     Brendan Higgins <brendanhiggins@...gle.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 Tue, Jun 30, 2020 at 11:47 PM Brendan Higgins
<brendanhiggins@...gle.com> wrote:
>
> 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.

Yes, sure. But I'm not only "researching", but using UML as a "router"
in one of my dev setups. 3363179385629c1804ea846f4e72608c2201a81e
mentions UML_NET_VECTOR incompatibility (and some other networking
options), which I had enabled and actually my whole dev networking is
based around UML_NET_VECTOR: I have two interfaces - one in raw mode
and one doing ipsec. All this was running in an empty "FROM: scratch"
container and obviously linked statically.

If the static linking breaks some other config options in allyesconfig
- that's another story, but I wanted to point out that config options
mentioned in the commit message worked just fine (if not trying to
resolve hostnames). In other words: if you don't resolve - glibc will
not try to load NSS. glibc-nss is a known problem and I would assume
most people trying to do static linking are aware of this - that is,
if they choose this path they are willing to live with the
consequences. That's why completely disabling the possibility sounds
too restrictive for me.

> 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.

If I succeed linking it to musl (or other non-glibc lib), would that be enough?

> 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?


As a side note: I tried to revert this patch and statically link 5.7
UML with glibc, but the binary still segfaults on start, so I would
assume it is not related to my previous attempts linking with musl.

Regards,
Ignat

>
> Cheers