This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 14/17 v5] Avoid stack-protecting signal-handling functions sibcalled from assembly.


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]