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

[Khem Raj]

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

Libtool adds -shared automatically for shared libraries so we have to
either insert pie before that which means make it part of TOOLCHAIN_OPTIONS
variable but that might have more unintended consequences especially for
external toolchains

>
>
> Here's an untested patch which puts -pie where it belongs in the final
> variables, without changing the pie/no pie API:
>
> diff --git a/meta/conf/distro/include/security_flags.inc
> b/meta/conf/distro/include/security_flags.inc
> index e162abeb3d9..b7b19355806 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -12,6 +12,9 @@ lcl_maybe_fortify =
> "${@base_conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE
>  # Error on use of format strings that represent possible security problems
>  SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
> -Werror=format-security"
>
> +# For history reasons and simplicity, -pie is listed here as part of
> CFLAGS.
> +# In practice, it ends up getting used as part of LDFLAGS, as it should
> +# be because it is a linker flag.
>  SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>  SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify}
> ${SECURITY_STRINGFORMAT}"
>
> @@ -94,8 +97,8 @@ SECURITY_STRINGFORMAT_pn-busybox = ""
>  SECURITY_STRINGFORMAT_pn-gcc = ""
>  SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
>
> -TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
> -TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
> +TARGET_CFLAGS_append_class-target = " ${@ oe.utils.filter_out('-pie',
> '${SECURITY_CFLAGS}') }"
> +TARGET_LDFLAGS_append_class-target = " ${@ oe.utils.filter('-pie',
> '${SECURITY_CFLAGS}') } ${SECURITY_

LDFLAGS}"
>
>  SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
>  SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
>
> --
> 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.
>
>
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>