(Sorry I didnt get back for a while)
After quite a journey I managed to work out how patch OpenWRT BB to build
using uClibc snapshot 2014097 and sourceware binutils 20140918.
For a MIPS target, all the symptoms remain:
- in spite of UCLIBC_BUILD_NOEXECSTACK=y, noexecstack is not present on
several so files
- in spite of UCLIBC_BUILD_RELRO=y, relro is not present in several so files
For noexecstack:
I dug right down into the build process and confirmed that -Wa,--noexecstack
is being applied at the assembler stage which is supposed to put noexecstack
on assembly files. Assuming that this was not working as intended, I then
applied the 'proper' way to fix assembly files,
http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart#Patching , to every
S file under all mips/ directories in the uClibc tree, noting that some other
architectures in uClibc do the same. After clean rebuilding this made no
difference.
As a further check I did a scan of every single .os / .oS file and disocevred
that not one did NOT have the NX flag. Which means that the problem is being
caused by the linker. There is no difference in linker options between the
libraries that have NX and those that dont.
In desparation I enabled ld tracing and verbose and discovered that for MIPS
targets the linked does some '/DISCARD/ : { *(.note.GNU-stack)' thing, so I
wonder if this is related?
The only way I was able to force noexecstack on every output was to use
UCLIBC_EXTRA_LDFLAGS=-Wl,-z,noexecstack in the build environment.
For relro:
I confirmed that -Wl,-z,relro -Wl,-z,now is on the linker line for the
affected libraries, and it works for some and not others.
My current understanding:
I think this problem is MIPS specific.
I built uClibc for x86 on native Debian Wheezy amd64 and every library had NX
and RELRO without doing anything special.
In summary, on MIPS architectures: if someone builds uClibc with
UCLIBC_BUILD_NOEXECSTACK=y or UCLIBC_BUILD_RELRO=y they wont be getting what
they asked for.
*Caveat* - it is highly possible there is something I still dont understand
about all this, and I will happily be enlightnened!
thanks,
--A
(I havent yet had a chance to look at the gentoo hardened mips uclibc
suggested previously.)
On 27/08/14 05:05, Bernhard Reutner-Fischer wrote:
On 25 August 2014 15:57, Andrew McDonnell <[email protected]> wrote:
On 25/08/14 22:56, Andrew McDonnell wrote:
Hmmm, I am having some trouble repeating my original result.
<snipped>
OK, with a fresh build, the following appears to apply:
* OpenWRT sets UCLIBC_BUILD_NOEXECSTACK=y
* Somehow this ends up with libcrypt, libm, libresolv, libnsl, libthread_db,
libdl and and libutil actually having the NX flag set in the ELF despite
there being no -Wl,-z,noexecstack linker option specified.
This I really do not understand yet!
* ld-uClibc, librt, libuClibc and libpthread _dont have the NX flag set, which
is what I would have expected when the link was missing the noexecstack option.
* The above was checked before any stripping applied, just in case
Now its gotten too late, so I'll have to re-test my patch that applies the
noexecstack marking to ld-uClibc, librt, libuClibc and libpthread as well
later this week before I submit it.
FWIW this is all done using the OpenWRT buildroot for a carambola2 target
There is another oddity with all of this, as well.
Every single one of libcrypt, libm, libresolv, libnsl, libthread_db, libdl,
libutil, libuClibc, librt and libpthread are all built with -Wl,-z-relro yet
the GNU_RELRO section is only present in libdl, libpthread and libuClibc and
yet all are built with exactly the same set of -Wl,-z options
I am wondering if this is this bug,
https://sourceware.org/bugzilla/show_bug.cgi?id=16322 because OpenWRT binutils
is still 2.23
I cannot reproduce this with binutils-gdb 2.24.51.20140818.
Can you try with binutils 2.24 or later please?
TIA,
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
