mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Joakim Sindholt <opensource@zhasha.com>
To: musl@lists.openwall.com
Subject: Re: [musl] Linking musl with -shared -static - is this supported?
Date: Tue, 24 May 2022 09:27:23 +0200	[thread overview]
Message-ID: <20220524092723.6459a5b7073e887af279820b@zhasha.com> (raw)
In-Reply-To: <b9f28430-ee74-dae2-05d7-2de474f9b0be@kazimierczak.name>

On Tue, 24 May 2022 07:54:43 +0200, Kuba Kazimierczak <kuba@kazimierczak.name> wrote:
> Hi, I'm on Alpine Linux, musl version 1.2.2. I'm attempting to create a 
> statically-linked shared object using "-shared -static" and use it in a 
> driver program as follows:

Musl does support building a statically linked shared object but it does
not (and cannot) support loading said object into another process with
its own libc, regardless of which libc it is.

> /tmp # cat lib.c
> #include <stdlib.h>
> 
> unsigned int add(unsigned int a, unsigned int b)
> {
>      free(malloc(1));
>      return (a+b);
> }
> /tmp # cat main.c
> #include <stdio.h>
> 
> extern unsigned int add(unsigned int a, unsigned int b);
> 
> int main(void)
> {
>      printf("%d\n", add(1,2));
>      return 0;
> }
> /tmp # clang-14 -g -c -fPIC lib.c
> /tmp # clang-14 -shared -static -o liblib.so lib.o
> /tmp # clang-14 -g -L. main.c -o main -llib
> /tmp # LD_LIBRARY_PATH=$PWD ./main
> Segmentation fault
> 
> The segfault happens in musl's malloc implementation internals:
> 
> #0  0x00007f9c882adc7a in get_random_secret () at 
> src/malloc/mallocng/glue.h:45
> #1  __malloc_alloc_meta () at src/malloc/mallocng/malloc.c:50
> #2  0x00007f9c882ae11b in alloc_group (req=1, sc=0) at 
> src/malloc/mallocng/malloc.c:179
> #3  alloc_slot (sc=sc@entry=0, req=req@entry=1) at 
> src/malloc/mallocng/malloc.c:291
> #4  0x00007f9c882ae646 in __libc_malloc_impl (n=1) at 
> src/malloc/mallocng/malloc.c:369
> #5  0x00007f9c882ad208 in add (a=1, b=2) at lib.c:5
> #6  0x000055909082f22e in main () at main.c:7
> 
> I see get_random_secret is trying to use struct __libc.argv, which is 
> probably not initialized in this case.
> 
> Is this use case supported at all?

You are entirely correct. The DSO you've built does not get to run its
instance of the dynamic linker which leaves all the libc-global data
uninitialized. Unfortunately just running the init won't give you a
functional environment.

Someone else asked roughly the same question half a year ago:
https://www.openwall.com/lists/musl/2022/01/01/1

Joakim

      reply	other threads:[~2022-05-24  7:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  5:54 Kuba Kazimierczak
2022-05-24  7:27 ` Joakim Sindholt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220524092723.6459a5b7073e887af279820b@zhasha.com \
    --to=opensource@zhasha.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).