From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29298 invoked from network); 5 Mar 2021 03:18:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2021 03:18:33 -0000 Received: (qmail 15863 invoked by uid 550); 5 Mar 2021 03:18:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15833 invoked from network); 5 Mar 2021 03:18:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney-org.20150623.gappssmtp.com; s=20150623; h=date:to:subject:from:message-id:user-agent:mime-version :content-transfer-encoding; bh=b3t6iMg9wwaEW4ir+mjdhkdFuz9w1I0o8rBRBodUjrs=; b=QS5EqAozy8emd/lfl23eggaM287fo90y0GzHq448quugbOKgMnpSkEkn3/KtdtF1DG zfz+R5syDufhFKUDACr6QoGE9+cq85ktcfBBi2nrlKoc0QbTaVamqmx8qzq7BxrAAOIx qqBaZWCvlIrCWjFODXqMlcBpZP7Vfk9/iZGBFM1U6SsIfQYkhK5Itk/XYqqLFu8RgQpL J6Aw43nCWIbjGoKKHpmUsBeoxwHEf6+eePj/eVNQDvpszeJke1miq8ABCMdFV7WCq1HN mePD9TxY8QYMUDJixHkIxx8y/rRxzK9hrK2Sn+dYSQhfGLN+u3WZsgMWnfzVIwuETRmB 6f6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:to:subject:from:message-id:user-agent :mime-version:content-transfer-encoding; bh=b3t6iMg9wwaEW4ir+mjdhkdFuz9w1I0o8rBRBodUjrs=; b=hGJHAIqc5RE9pvi6Mm9RL2lZVcUWNaUTF7OR0k8knqGmpFN+m10lYpz9VqIq3R1gq/ 7fI7Z/MiDWPdfyf+H0Af8z4qQBvK3z0s5ARsbpcWEARQrs/gEWI3+V3HekxCEF0TcbLb 9NlJ+Pi6nqdW5eAqBFw1ya4x1sxlsSxIMjN6g5T/9fauqbUruhHTITBtt6wg/0ySNEgb bTSQ3x/5G3s6OaTQ0LRxXadR96d2UWAf8+l7uXXli6SNlkXZKuL2KIeelUF405j6DSMO foJ2bJpXDk3Qk0VGxcNq880QgdkAsUtHKMmNG/lYF1mYRQqX3YEBM3CRv4My5vP22h0n vOoA== X-Gm-Message-State: AOAM530t5E3Y/K8BfvBFB8mqoezCQFBNTHPXOUFMyujUWKQ7QtRVKus6 5ujMnPFpp5Q4FNQaYeB6nCJHnyazABotj2bAChE= X-Google-Smtp-Source: ABdhPJz7xKJDjeUbiZg4xSv9N3rqAiHbMEpPqsHBpAQ97sIJBNKqiL49vSzaAG94gIQCN5dMuWfvhQ== X-Received: by 2002:a63:531e:: with SMTP id h30mr6521436pgb.158.1614914293221; Thu, 04 Mar 2021 19:18:13 -0800 (PST) Date: Thu, 04 Mar 2021 19:18:11 -0800 To: musl@lists.openwall.com From: Michael Forney Message-Id: <2XR4N9WTZJRRB.388AF1JAC0M8E@mforney.org> User-Agent: mblaze/1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [musl] ld-musl-* and empty .eh_frame Hi, =C3=89rico noticed that cproc (my C compiler) produced executables that musl's dynamic linker fails to load when passed as an argument: /lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program However, running ./t directly works fine. It turns out that this is because the executables have an empty .eh_frame section, which causes musl to attempt an mmap with length 0 which fails with EINVAL. GNU ld seems to always create a .eh_frame section in the final executable (unless you pass --no-ld-generated-unwind-info), regardless of whether any of the objects had one. Since none of the objects I built have an .eh_frame and none of musl's crt*.o have one, it ends up empty. gcc does not have this problem because its crtend.o has a non-empty .eh_frame (size is 4, so looks to be a CIE terminator according to LSB[0]).= Here's a short shell session demonstrating the problem: $ cat t.s .text .globl main main: movl $123, %eax ret $ as -o t.o t.s $ ld --dynamic-linker /lib/ld-musl-x86_64.so.1 -o t /lib/crt1.o /lib/crti= .o t.o /lib/libc.so /lib/crtn.o $ ./t ; echo $? 123 $ /lib/ld-musl-x86_64.so.1 ./t /lib/ld-musl-x86_64.so.1: ./t: Not a valid dynamic program $ strace /lib/ld-musl-x86_64.so.1 ./t execve("/lib/ld-musl-x86_64.so.1", ["/lib/ld-musl-x86_64.so.1", "./t"], 0= x7ffd8c17e4e8 /* 34 vars */) =3D 0 arch_prctl(ARCH_SET_FS, 0x7f3691752aa8) =3D 0 set_tid_address(0x7f3691754fd8) =3D 31726 open("./t", O_RDONLY|O_LARGEFILE) =3D 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0 \20@\0\0\0\0\0"..= ., 960) =3D 960 mmap(0x400000, 16384, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0x400000 mmap(0x401000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x100= 0) =3D 0x401000 mmap(0x402000, 0, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) =3D -1 EIN= VAL (Invalid argument) munmap(0x400000, 16384) =3D 0 writev(2, ["/lib/ld-musl-x86_64.so.1: ./t: N"...59, NULL0], 2/lib/ld-musl= -x86_64.so.1: ./t: Not a valid dynamic program ) =3D 59 exit_group(1) =3D ? +++ exited with 1 +++ $ This leaves me with a few questions: 1. Is it invalid for an ELF executable to have an empty .eh_frame section? The only documentation I could find about it is [0], which says that it must contain one or more CFI records, so 0 would be invalid. 2. Is it the compiler's responsibility to link with an object containing a CIE terminator (like gcc's crtend.o) to prevent an empty .eh_frame section? 3. Is it a bug that GNU ld creates an empty .eh_frame by default, even when none of the objects it is linking have one? It looks like lld does not create an .eh_frame in this case. 4. Should musl's ld.so be able to handle such executables? The kernel does not seem to have a problem with it, as well glibc's ld.so with an executable I crafted with a 0-length .eh_frame section. Or perhaps some combination of the four? Any insight is appreciated. Thanks! [0] https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframec= hpt.html