This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 14/17 v5] Avoid stack-protecting signal-handling functions sibcalled from assembly.
- From: Nix <nix at esperi dot org dot uk>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 15 May 2016 10:50:10 +0100
- Subject: Re: [PATCH 14/17 v5] Avoid stack-protecting signal-handling functions sibcalled from assembly.
- Authentication-results: sourceware.org; auth=none
- References: <1457882222-22599-1-git-send-email-nix at esperi dot org dot uk> <1457882222-22599-15-git-send-email-nix at esperi dot org dot uk> <3a1025f2-8b0e-5d9b-01c4-7b4e4ef62cc8 at redhat dot com>
On 13 May 2016, Florian Weimer told this:
> On 03/13/2016 04:16 PM, Nix wrote:
>> Certain signal-handling functions are sibcalled from assembly on
>> x86, both on Linux and the Hurd. As such, they depend on having
>> the same-shaped stack frame, an assumption it seems likely that
>> -fstack-protector violates.
[...]
> The lack of rebuild is more problematic. Does it really make a
> difference, considering that the affected function is not active while
> we initialize the stack guard value?
Oh yes it really does. We're not just keeping stack-protection out of
ld.so because that's where the canary is initialized, but also because
ld.so doesn't have __libc_message() et al. If a single reference is
missed we end up dragging all of the __libc_message() machinery, libio,
etc, into ld.so. We could fix this by providing a small stub for
__libc_message() or __fortify_fail() in ld.so, but given that this
behaviour also prevents any references from creeping in to ld.so's more
delicate machinery, this seems like a better first step. We can try to
stack-protect ld.so later :)
To be specific, because of this rebuild error, sigjmp.c stays
stack-protected, so we see this:
make[3]: Leaving directory '/home/oranix/oracle/src/glibc/elf'
gcc -nostdlib -nostartfiles -r -o /usr/local/tmp/test/1/elf/librtld.os '-Wl,-(' /usr/local/tmp/test/1/elf/dl-allobjs.os /usr/local/tmp/test/1/elf/rtld-libc.a -lgcc '-Wl,-)' \
-Wl,-Map,/usr/local/tmp/test/1/elf/librtld.os.map
gcc -nostdlib -nostartfiles -shared -o /usr/local/tmp/test/1/elf/ld.so.new \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,now \
/usr/local/tmp/test/1/elf/librtld.os -Wl,--version-script=/usr/local/tmp/test/1/ld.map \
-Wl,-soname=ld-linux-x86-64.so.2 \
-Wl,-defsym=_begin=0
/usr/local/tmp/test/1/elf/librtld.os: In function `check_one_fd':
/home/oranix/oracle/src/glibc/csu/check_fds.c:84: undefined reference to `__stack_chk_fail'
/usr/local/tmp/test/1/elf/librtld.os: In function `__libc_check_standard_fds':
/home/oranix/oracle/src/glibc/csu/check_fds.c:100: undefined reference to `__stack_chk_fail'
/usr/local/tmp/test/1/elf/librtld.os: In function `__closedir':
/home/oranix/oracle/src/glibc/dirent/../sysdeps/posix/closedir.c:53: undefined reference to `__stack_chk_fail'
/usr/local/tmp/test/1/elf/librtld.os: In function `__readdir':
/home/oranix/oracle/src/glibc/dirent/../sysdeps/posix/readdir.c:118: undefined reference to `__stack_chk_fail'
/usr/local/tmp/test/1/elf/librtld.os: In function `__rewinddir':
/home/oranix/oracle/src/glibc/dirent/../sysdeps/posix/rewinddir.c:39: undefined reference to `__stack_chk_fail'
/usr/local/tmp/test/1/elf/librtld.os:/home/oranix/oracle/src/glibc/dirent/../sysdeps/unix/sysv/linux/getdents.c:301: more undefined references to `__stack_chk_fail' follow
collect2: error: ld returned 1 exit status
This is obviously a bad thing.
I'll have a hunt for whatever it is that's causing sigjmp.c to not be
rebuilt after this test cycle, because that's the underlying bug here,
really.
--
NULL && (void)