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

[Patrick Ohly]

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 file is not present at all without the patch. If anyone has a clue
about what might be causing that, I'm all ears...

-- 
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.