On 1 October 2014 16:34, Andrew McDonnell <[email protected]> wrote: > (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:
Do you use a plain gcc? You might want to look at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02430.html (for example). HTH, > > - 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
