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