From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: libc-alpha@sourceware.org, glibc@packages.debian.org
Subject: static pie: confusion between _DYNAMIC, crt1.o, Scrt1.o
Date: Sat, 22 Oct 2022 16:06:14 +0200 [thread overview]
Message-ID: <20221022140614.rnfd4d4nefjmizzi@begin> (raw)
Hello,
We're seeing a missing _DYNAMIC symbol here:
https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=hurd-i386&ver=2.2.40-1&stamp=1666261690&raw=0
which is leaving me completely confused.
gcc -I/usr/include -I/usr/include -Wall -Wno-format-zero-length -Wno-pointer-sign -Wpointer-arith -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -pie -static -o gpgv gpgv.o build-packet.o compress.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o rmd160.o openfile.o keyid.o parse-packet.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o ecdh.o verify.o ../kbx/libkeybox.a ../common/libcommon.a ../regexp/libregexp.a ../common/libgpgrl.a -lz -L/usr/lib/i386-gnu -lgcrypt -L/usr/lib/i386-gnu -lgpg-error
[...]
/usr/bin/ld: /usr/lib/i386-gnu/libcrt.a(dl-reloc-static-pie.o): in function `_dl_relocate_static_pie':
(.text+0x31): undefined reference to `_DYNAMIC'
So this is static pie (-pie -static), and I'm getting just the same
issue with a mere int main(void) {} built with -static -pie.
When debugging a bit on Debian Hurd:
$ gcc test.o -o test -pie -static -v
[...]
/usr/lib/gcc/i686-gnu/12/collect2 -plugin /usr/lib/gcc/i686-gnu/12/liblto_plugin.so -plugin-opt=/usr/lib/gcc/i686-gnu/12/lto-wrapper -plugin-opt=-fresolution=/tmp/ccR0YAaP.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc --build-id -m elf_i386 --hash-style=gnu --as-needed -static -o test /usr/lib/gcc/i686-gnu/12/../../../i386-gnu/Scrt1.o /usr/lib/gcc/i686-gnu/12/../../../i386-gnu/crti.o /usr/lib/gcc/i686-gnu/12/crtbeginT.o -L/usr/lib/gcc/i686-gnu/12 -L/usr/lib/gcc/i686-gnu/12/../../../i386-gnu -L/usr/lib/gcc/i686-gnu/12/../../.. -L/lib/i386-gnu -L/usr/lib/i386-gnu test.o --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/i686-gnu/12/crtend.o /usr/lib/gcc/i686-gnu/12/../../../i386-gnu/crtn.o
So this is using Scrt1.o, which doesn't surprise me since we're linking
with pie. Scrt1.o doesn't define _dl_relocate_static_pie, so I'm not
surprised that the link then pulls dl-reloc-static-pie.o from libc.a,
which thus requires _DYNAMIC, but that's not defined...
Testing this on Debian Linux:
$ gcc test.o -o test -pie -static -v
[...]
/usr/lib/gcc/x86_64-linux-gnu/12/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/12/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper -plugin-opt=-fresolution=/tmp/ccHeGHCw.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc --build-id -m elf_x86_64 --hash-style=gnu --as-needed -static -o test /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/12/crtbeginT.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/12/../../.. test.o --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/x86_64-linux-gnu/12/crtend.o /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/crtn.o
This is using crt1.o rather than Scrt1.o, why?
Since crt1.o defines _dl_relocate_static_pie (to a trivial ret),
dl-reloc-static-pie.o doesn't get pulled and thus no problem there. But
isn't Scrt1.o supposed to be used and _dl_relocate_static_pie supposed
to actually do some work?
Trying the resulting binary of this source:
#include <stdio.h>
int main(void) { printf("%p\n", printf); }
$ ./test
0x4096c0
$ ./test
0x4096c0
so this is actually missing the whole point of using PIE: ASLR. So
something looks completely wrong here?
Samuel
next reply other threads:[~2022-10-22 14:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-22 14:06 Samuel Thibault [this message]
2022-10-22 14:25 ` Xi Ruoyao
2022-10-22 14:45 ` Samuel Thibault
2022-10-23 2:08 ` Xi Ruoyao
2022-10-23 9:43 ` Samuel Thibault
2022-10-24 10:11 ` Florian Weimer
2022-10-24 10:33 ` Samuel Thibault
2022-10-24 11:12 ` Florian Weimer
2022-10-24 15:56 ` Mike Frysinger
2022-10-24 17:36 ` Florian Weimer
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=20221022140614.rnfd4d4nefjmizzi@begin \
--to=samuel.thibault@ens-lyon.org \
--cc=glibc@packages.debian.org \
--cc=libc-alpha@sourceware.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).