Message ID | 20200624212319.403689-1-ignat@cloudflare.com |
---|---|
State | Superseded |
Headers | show |
Series | [RFC] Revert "um: Make CONFIG_STATIC_LINK actually static" | expand |
On Wed, Jun 24, 2020 at 2:23 PM Ignat Korchagin <ignat@cloudflare.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
On Tue, Jun 30, 2020 at 11:47 PM Brendan Higgins <brendanhiggins@google.com> wrote: > > On Wed, Jun 24, 2020 at 2:23 PM Ignat Korchagin <ignat@cloudflare.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
diff --git a/arch/um/Kconfig b/arch/um/Kconfig index 96ab7026b037..817a4c838a06 100644 --- a/arch/um/Kconfig +++ b/arch/um/Kconfig @@ -62,12 +62,9 @@ config NR_CPUS source "arch/$(HEADER_ARCH)/um/Kconfig" -config FORBID_STATIC_LINK - bool - config STATIC_LINK bool "Force a static link" - depends on !FORBID_STATIC_LINK + default n help This option gives you the ability to force a static link of UML. Normally, UML is linked as a shared binary. This is inconvenient for @@ -76,9 +73,6 @@ config STATIC_LINK Additionally, this option enables using higher memory spaces (up to 2.75G) for UML. - NOTE: This option is incompatible with some networking features which - depend on features that require being dynamically loaded (like NSS). - config LD_SCRIPT_STATIC bool default y diff --git a/arch/um/drivers/Kconfig b/arch/um/drivers/Kconfig index 9160ead56e33..72d417055782 100644 --- a/arch/um/drivers/Kconfig +++ b/arch/um/drivers/Kconfig @@ -234,7 +234,6 @@ config UML_NET_DAEMON config UML_NET_VECTOR bool "Vector I/O high performance network devices" depends on UML_NET - select FORBID_STATIC_LINK help This User-Mode Linux network driver uses multi-message send and receive functions. The host running the UML guest must have @@ -246,7 +245,6 @@ config UML_NET_VECTOR config UML_NET_VDE bool "VDE transport (obsolete)" depends on UML_NET - select FORBID_STATIC_LINK help This User-Mode Linux network transport allows one or more running UMLs on a single host to communicate with each other and also @@ -294,7 +292,6 @@ config UML_NET_MCAST config UML_NET_PCAP bool "pcap transport (obsolete)" depends on UML_NET - select FORBID_STATIC_LINK help The pcap transport makes a pcap packet stream on the host look like an ethernet device inside UML. This is useful for making
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. Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> --- arch/um/Kconfig | 8 +------- arch/um/drivers/Kconfig | 3 --- 2 files changed, 1 insertion(+), 10 deletions(-)