Question - intention of UCLIBC_BUILD_NOEXECSTACK?

[Andrew McDonnell]

(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 <bugs at andrewmcdonnell.net> 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,
>