Question - intention of UCLIBC_BUILD_NOEXECSTACK?

[Bernhard Reutner-Fischer]

On 1 October 2014 16:34, Andrew McDonnell <bugs at andrewmcdonnell.net> 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 <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,
>>
>