[oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1)

[Khem Raj]

Patrick

I have a patchset that is redoing the PIE hardening with using some help
from gcc configuration itself. with this patch almost all of the NOPIE entries
in secuity.inc are fixed and we get gcc to take care of -pie passing to compiler
and linker when needed

This patches are done after gcc7 recipes so I will propose them after gcc7 but
if you are interested here is the branch

Top 6 patches are what you want from
http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master


On Mon, Jun 12, 2017 at 12:04 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Fri, 2017-06-09 at 19:32 +0200, Patrick Ohly wrote:
>> On Fri, 2017-06-09 at 16:34 +0200, Patrick Ohly wrote:
>> > On Fri, 2017-06-09 at 13:24 +0000, Khem Raj wrote:
>> > >
>> > > On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly <patrick.ohly at intel.com>
>> > > wrote:
>> > >
>> > >         On Wed, 2017-06-07 at 21:44 +0000, Peter Kjellerstedt wrote:
>> > >         > My guess is that the problem stems from the fact that
>> > >         security_flags.inc
>> > >         > adds -pie (which is a linker flag) to SECURITY_CFLAGS rather
>> > >         than
>> > >         > SECURITY_LDFLAGS...
>> > >
>> > >         I think I've seen that cause problems elsewhere when the
>> > >         CFLAGS came
>> > >         after -shared, because then the compiler ended up trying to
>> > >         produce a
>> > >         pie executable instead of a shared library.
>> > >
>> > >         Perhaps we should finally address that in security_flags.inc
>> > >         instead of
>> > >         working around it?
>> > >
>> > >
>> > > This patch is removing -pie from compiler and linker flags which does
>> > > not result in intended behavior for executable when linked they will
>> > > not be using -pie
>> >
>> > The patch had some syntax errors (fixed version below), but it had the
>> > code which adds -pie to TARGET_LDFLAGS when it is in SECURITY_CFLAGS, so
>> > conceptually the flag shouldn't get lost entirely.
>> >
>> > Are you saying that one cannot rely on TARGET_LDFLAGS being used during
>> > linking?
>> >
>> > I've tested with m4, and it seems to work okay:
>> >
>> > $ grep -w -e -pie tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/temp/log.do_compile
>> > x86_64-refkit-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot   -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0=/usr/src/debug/m4/1.4.18-r0 -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot-native= -fdebug-prefix-map=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/recipe-sysroot=  -fstack-protector-strong -fpie -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -pie -fstack-protector-strong -Wl,-z,relro,-z,now -o m4 m4.o builtin.o debug.o eval.o format.o freeze.o input.o macro.o output.o path.o symtab.o ../lib/libm4.a
>> >
>> > $ file tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4
>> > tmp-glibc/work/corei7-64-refkit-linux/m4/1.4.18-r0/packages-split/m4/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=f10d0a26299dcb8c5bd0f1c82ed492aea2d8f0ac, stripped
>> >
>> > I assume "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB
>> > executable" means "pie executable"?
>>
>> While I don't think my patch caused -pie to get lost, unfortunately I
>> now know that it still doesn't go into the right place in all cases. For
>> example, ncurses puts LDFLAGS after -shared, thus triggering the "main
>> undefined" error.
>>
>> The TOOLCHAIN_OPTIONS that Khem mentioned get appended directly after
>> the command, so that seems like a better place for -pie than LDFLAGS.
>> It's still a bit odd to pass a linker flag to all compiler invocations,
>> including those that do not link, but it might be a pragmatic solution
>> that is better than what we have now.
>>
>> However, my patch below now causes /usr/lib/libstdc++.a-gdb.py to be
>> built for gcc-runtime, which triggers an error:
>>
>> ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime:
>> Files/directories were installed but not shipped in any package:
>>   /usr/lib/libstdc++.a-gdb.py
>
> That's just a minor follow-up error. The real problem is that libstdc
> ++.so.6.0.22 was not getting built anymore. The expect .py file then is
> libstdc++.so.6.0.22-gdb.py.
>
> I'm still unsure about the root cause. Something seems to have gone
> wrong when building the toolchain, because gcc-runtime doesn't even have
> -pie in the compiler flags. From log.do_configure:
>
> checking whether the x86_64-refkit-linux-gcc  -m64 -march=corei7
> -mtune=corei7 -mfpmath=sse -msse4.2
> --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/gcc-runtime/6.3.0-r0/recipe-sysroot  -Wl,-z,relro,-z,now linker (x86_64-refkit-linux-ld --sysroot=/fast/build/refkit/intel-corei7-64/tmp-glibc/work/corei7-64-refkit-linux/gcc-runtime/6.3.0-r0/recipe-sysroot  -Wl,-z,relro,-z,now   -m elf_x86_64) supports shared libraries... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... unsupported
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... no
>
> I'm going to put this aside for now, but I remain unhappy about how we
> currently pass -pie in CFLAGS and the workarounds that are getting used
> as a result of that, like disabling -pie for Python distutils. I
> understand that that particular change probably only affected very few
> binaries, but it still looks like a workaround and not a proper solution
> to me.
>
> What do others thing about the current status quo regarding -pie?
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>