[meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1

[meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1

[Adam C. Foltzer]

Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
---
 meta-oe/recipes-devtools/meson/{meson_0.37.1.bb => meson_0.40.1.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta-oe/recipes-devtools/meson/{meson_0.37.1.bb => meson_0.40.1.bb} (88%)

diff --git a/meta-oe/recipes-devtools/meson/meson_0.37.1.bb b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
similarity index 88%
rename from meta-oe/recipes-devtools/meson/meson_0.37.1.bb
rename to meta-oe/recipes-devtools/meson/meson_0.40.1.bb
index dbbea64..fd96b42 100644
--- a/meta-oe/recipes-devtools/meson/meson_0.37.1.bb
+++ b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
@@ -9,7 +9,7 @@ SRC_URI = " \
     file://native_bindir.patch \
 "
 
-SRCREV = "3d4bfdcb22314ea7db45a5b075f8b2a9c1498aab"
+SRCREV = "b25d3e4d3f2b4d37029a507cc089bdde643c6240"
 
 S = "${WORKDIR}/git"
 
-- 
2.9.4

[meta-oe][PATCH 2/3] meson: fix build/host confusion for bbclass

[Adam C. Foltzer]

Meson and Bitbake use different terminology for the build and host;
this provides the correct build machine info to Meson.

Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
---
 meta-oe/classes/meson.bbclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-oe/classes/meson.bbclass b/meta-oe/classes/meson.bbclass
index c33174a..d2ae626 100644
--- a/meta-oe/classes/meson.bbclass
+++ b/meta-oe/classes/meson.bbclass
@@ -66,9 +66,9 @@ c_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
 cpp_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
 
 [host_machine]
-system = '${HOST_OS}'
-cpu_family = '${HOST_ARCH}'
-cpu = '${HOST_ARCH}'
+system = '${BUILD_OS}'
+cpu_family = '${BUILD_ARCH}'
+cpu = '${BUILD_ARCH}'
 endian = '${MESON_HOST_ENDIAN}'
 
 [target_machine]
-- 
2.9.4

[meta-oe][PATCH 3/3] meson: add LDFLAGS to bbclass C/C++ link arguments

[Adam C. Foltzer]

This adds compiler flags for C++ projects, and fixes the linker
arguments for both C and C++ to avoid the GNU_HASH qa failure

Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
---
 meta-oe/classes/meson.bbclass | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta-oe/classes/meson.bbclass b/meta-oe/classes/meson.bbclass
index d2ae626..11c8d34 100644
--- a/meta-oe/classes/meson.bbclass
+++ b/meta-oe/classes/meson.bbclass
@@ -32,7 +32,8 @@ MESONOPTS = " --prefix ${prefix} \
               --localstatedir ${localstatedir} \
               --sharedstatedir ${sharedstatedir}"
 
-MESON_C_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_C_ARGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_LINK_ARGS = "${TOOLCHAIN_OPTIONS} ${LDFLAGS}"
 
 MESON_HOST_ENDIAN = "${@bb.utils.contains('SITEINFO_ENDIANNESS', 'be', 'big', 'little', d)}"
 MESON_TARGET_ENDIAN = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'big', 'little', d)}"
@@ -61,9 +62,9 @@ pkgconfig = 'pkg-config'
 
 [properties]
 c_args = [${@meson_array('MESON_C_ARGS', d)}]
-cpp_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
-c_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
-cpp_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
+c_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
+cpp_args = [${@meson_array('MESON_C_ARGS', d)}]
+cpp_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
 
 [host_machine]
 system = '${BUILD_OS}'
-- 
2.9.4

Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Adam C. Foltzer
> Sent: den 5 juni 2017 19:23
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [meta-oe][PATCH 1/3] meson: update Meson devtool to
> 0.40.1
> 
> Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
> ---
>  meta-oe/recipes-devtools/meson/{meson_0.37.1.bb => meson_0.40.1.bb} |
> 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta-oe/recipes-devtools/meson/{meson_0.37.1.bb =>
> meson_0.40.1.bb} (88%)
> 
> diff --git a/meta-oe/recipes-devtools/meson/meson_0.37.1.bb b/meta-
> oe/recipes-devtools/meson/meson_0.40.1.bb
> similarity index 88%
> rename from meta-oe/recipes-devtools/meson/meson_0.37.1.bb
> rename to meta-oe/recipes-devtools/meson/meson_0.40.1.bb
> index dbbea64..fd96b42 100644
> --- a/meta-oe/recipes-devtools/meson/meson_0.37.1.bb
> +++ b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
> @@ -9,7 +9,7 @@ SRC_URI = " \
>      file://native_bindir.patch \
>  "
> 
> -SRCREV = "3d4bfdcb22314ea7db45a5b075f8b2a9c1498aab"
> +SRCREV = "b25d3e4d3f2b4d37029a507cc089bdde643c6240"
> 
>  S = "${WORKDIR}/git"
> 
> --
> 2.9.4

When I updated the meson recipe to 0.37.1, I did not update it to the 
latest version at the time (0.38 something if I remember correctly)
because the latter version failed to build shared libraries if building 
with PIE had been enabled by including security_flags.inc. I had 
planned to look into that, but never got around to it. If you have not 
tried building with PIE enabled, you should try that as it probably 
still causes build problems with 0.40.1...

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

//Peter

Re: [meta-oe][PATCH 3/3] meson: add LDFLAGS to bbclass C/C++ link arguments

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Adam C. Foltzer
> Sent: den 5 juni 2017 19:23
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] [meta-oe][PATCH 3/3] meson: add LDFLAGS to bbclass C/C++
> link arguments
> 
> This adds compiler flags for C++ projects, and fixes the linker
> arguments for both C and C++ to avoid the GNU_HASH qa failure
> 
> Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
> ---
>  meta-oe/classes/meson.bbclass | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/meta-oe/classes/meson.bbclass b/meta-
> oe/classes/meson.bbclass
> index d2ae626..11c8d34 100644
> --- a/meta-oe/classes/meson.bbclass
> +++ b/meta-oe/classes/meson.bbclass
> @@ -32,7 +32,8 @@ MESONOPTS = " --prefix ${prefix} \
>                --localstatedir ${localstatedir} \
>                --sharedstatedir ${sharedstatedir}"
> 
> -MESON_C_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
> +MESON_C_ARGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}"
> +MESON_LINK_ARGS = "${TOOLCHAIN_OPTIONS} ${LDFLAGS}"

According to a colleague of mine, the ${TARGET_CC_ARCH} options need 
to be passed to the linker as well or binaries end up with the wrong 
ld.so for armhf.

Also, why do you need to add ${LDFLAGS} here?

>  MESON_HOST_ENDIAN = "${@bb.utils.contains('SITEINFO_ENDIANNESS', 'be',
> 'big', 'little', d)}"
>  MESON_TARGET_ENDIAN = "${@bb.utils.contains('TUNE_FEATURES',
> 'bigendian', 'big', 'little', d)}"
> @@ -61,9 +62,9 @@ pkgconfig = 'pkg-config'
> 
>  [properties]
>  c_args = [${@meson_array('MESON_C_ARGS', d)}]
> -cpp_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
> -c_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
> -cpp_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
> +c_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
> +cpp_args = [${@meson_array('MESON_C_ARGS', d)}]
> +cpp_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
> 
>  [host_machine]
>  system = '${BUILD_OS}'
> --
> 2.9.4

//Peter

[meta-oe][PATCH v2] meson: add LDFLAGS to bbclass C/C++ link

[Adam C. Foltzer]

When testing this patch on a 32-bit ARM target, I found that it does
indeed need TARGET_CC_ARCH in order to link to the right ld.so.

The addition of LDFLAGS makes sure the --hash-style=gnu argument got
passed along—the qa step was failing for my 64-bit ARM target without
this option.

Regards,
Adam

[meta-oe][PATCH v2] meson: add LDFLAGS to bbclass C/C++ link arguments

[Adam C. Foltzer]

This adds compiler flags for C++ projects, and fixes the linker
arguments for both C and C++ to avoid the GNU_HASH qa failure

Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
---
 meta-oe/classes/meson.bbclass                  | 11 ++++++-----
 meta-oe/recipes-devtools/meson/meson_0.40.1.bb |  1 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta-oe/classes/meson.bbclass b/meta-oe/classes/meson.bbclass
index d2ae626..2c48a7e 100644
--- a/meta-oe/classes/meson.bbclass
+++ b/meta-oe/classes/meson.bbclass
@@ -32,7 +32,8 @@ MESONOPTS = " --prefix ${prefix} \
               --localstatedir ${localstatedir} \
               --sharedstatedir ${sharedstatedir}"
 
-MESON_C_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_C_ARGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_LINK_ARGS = "${MESON_C_ARGS} ${LDFLAGS}"
 
 MESON_HOST_ENDIAN = "${@bb.utils.contains('SITEINFO_ENDIANNESS', 'be', 'big', 'little', d)}"
 MESON_TARGET_ENDIAN = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'big', 'little', d)}"
@@ -61,9 +62,9 @@ pkgconfig = 'pkg-config'
 
 [properties]
 c_args = [${@meson_array('MESON_C_ARGS', d)}]
-cpp_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
-c_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
-cpp_link_args = [${@meson_array('TOOLCHAIN_OPTIONS', d)}]
+c_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
+cpp_args = [${@meson_array('MESON_C_ARGS', d)}]
+cpp_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
 
 [host_machine]
 system = '${BUILD_OS}'
@@ -74,7 +75,7 @@ endian = '${MESON_HOST_ENDIAN}'
 [target_machine]
 system = '${TARGET_OS}'
 cpu_family = '${TARGET_ARCH}'
-cpu = '${TARGET_ARCH}'
+cpu = '${TUNE_PKGARCH}'
 endian = '${MESON_TARGET_ENDIAN}'
 EOF
 }
diff --git a/meta-oe/recipes-devtools/meson/meson_0.40.1.bb b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
index fd96b42..a2c5e4d 100644
--- a/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
+++ b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
@@ -6,7 +6,6 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=3b83ef96387f14655fc854ddc3c6bd57"
 
 SRC_URI = " \
     git://github.com/mesonbuild/meson.git \
-    file://native_bindir.patch \
 "
 
 SRCREV = "b25d3e4d3f2b4d37029a507cc089bdde643c6240"
-- 
2.9.4

Re: [meta-oe][PATCH v2] meson: add LDFLAGS to bbclass C/C++ link arguments

[Khem Raj]

On Thu, Jun 8, 2017 at 10:34 AM, Adam C. Foltzer <acfoltzer@galois.com> wrote:
> -cpu = '${TARGET_ARCH}'
> +cpu = '${TUNE_PKGARCH}'

what is this change for ?

Re: [meta-oe][PATCH v2] meson: add LDFLAGS to bbclass C/C++ link arguments

[Adam Foltzer]

Apologies, this line was inadvertently committed. It was a fix I tried
before learning that adding TARGET_CC_ARCH was the solution to linking the
wrong ld.so.

On Thu, Jun 8, 2017 at 10:45 AM Khem Raj <raj.khem@gmail.com> wrote:

> On Thu, Jun 8, 2017 at 10:34 AM, Adam C. Foltzer <acfoltzer@galois.com>
> wrote:
> > -cpu = '${TARGET_ARCH}'
> > +cpu = '${TUNE_PKGARCH}'
>
> what is this change for ?
>

Re: [meta-oe][PATCH 1/3] meson: update Meson devtool to 0.40.1

[Martin Jansa]

Doesn't work well with some other meson changes we have:

http://errors.yoctoproject.org/Errors/Details/144180/

On Mon, Jun 5, 2017 at 7:23 PM, Adam C. Foltzer <acfoltzer@galois.com>
wrote:

> Signed-off-by: Adam C. Foltzer <acfoltzer@galois.com>
> ---
>  meta-oe/recipes-devtools/meson/{meson_0.37.1.bb => meson_0.40.1.bb} | 2
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta-oe/recipes-devtools/meson/{meson_0.37.1.bb => meson_0.40.1.bb}
> (88%)
>
> diff --git a/meta-oe/recipes-devtools/meson/meson_0.37.1.bb
> b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
> similarity index 88%
> rename from meta-oe/recipes-devtools/meson/meson_0.37.1.bb
> rename to meta-oe/recipes-devtools/meson/meson_0.40.1.bb
> index dbbea64..fd96b42 100644
> --- a/meta-oe/recipes-devtools/meson/meson_0.37.1.bb
> +++ b/meta-oe/recipes-devtools/meson/meson_0.40.1.bb
> @@ -9,7 +9,7 @@ SRC_URI = " \
>      file://native_bindir.patch \
>  "
>
> -SRCREV = "3d4bfdcb22314ea7db45a5b075f8b2a9c1498aab"
> +SRCREV = "b25d3e4d3f2b4d37029a507cc089bdde643c6240"
>
>  S = "${WORKDIR}/git"
>
> --
> 2.9.4
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

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

[Patrick Ohly]

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?

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.

Re: -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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: -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 13:24 +0000, Khem Raj wrote:
> 
> On Fri, Jun 9, 2017 at 1:43 AM Patrick Ohly <patrick.ohly@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"?

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index e162abeb3d9..b1781ceab42 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.str_filter_out('-pie', '${SECURITY_CFLAGS}', d) }"
+TARGET_LDFLAGS_append_class-target = " ${@ oe.utils.str_filter('-pie', '${SECURITY_CFLAGS}', d) } ${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.

Re: -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@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.

Re: -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@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.

Re: -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@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@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.
>
>
>

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

[Peter Kjellerstedt]

This looks great, except for one thing. What about external toolchains?

We use Poky's compiler when building for ARM, but when building for 
MIPS we need to use our own, which is based on gcc 4.7.2 and not 
likely to be updated. With the suggested changes to security_flags.inc 
we will no longer be able to build with hardening enabled for MIPS...

Regarding your changes:
* Wouldn't it be better to define GCCPIE as:
    GCCPIE ??= ""
  in meta/recipes-devtools/gcc/gcc-configure-common.inc and as:
    GCCPIE ?= "--enable-default-pie"
  in meta/conf/distro/include/security_flags.inc? That way it is easy 
  to disable PIE by setting GCCPIE = "" in local.conf even if other 
  hardenings are enabled by including security_flags.inc.
* It is probably a bad idea to change the definition of 
  SECURITY_NO_PIE_CFLAGS to:
    SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_CFLAGS}"
  since it is most likely used to define SECURITY_CFLAGS in other 
  existing layers via the typical:
    SECURITY_CFLAGS_pn-foo = "${SECURITY_NO_PIE_CFLAGS}"
  and you will then end up with a circular definition...

For backwards compatibility it might be an idea to do the following 
in security_flags.inc:

GCCPIE ?= "--enable-default-pie"

# SECURITY_PIE_CFLAGS is used to maintain backwards compatibility for 
# the definitions of SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS after 
# the introduction of GCCPIE.
SECURITY_PIE_CFLAGS ?= "${@'' if '${GCCPIE}' else '-pie -fpie'}"
SECURITY_CFLAGS ?= "-fstack-protector-strong ${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"

That way the SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS variables 
would keep their old values unless GCCPIE is set to something, which 
it is by default.

Enabling hardening but without PIE would then become:

GCCPIE = ""
SECURITY_PIE_CFLAGS = ""

//Peter

> -----Original Message-----
> From: Khem Raj [mailto:raj.khem@gmail.com]
> Sent: den 12 juni 2017 16:47
> To: Patrick Ohly <patrick.ohly@intel.com>
> Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; openembedded-
> devel@lists.openembedded.org
> Subject: Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH
> 1/3] meson: update Meson devtool to 0.40.1)
> 
> 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@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@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.
> >
> >
> >

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

[Khem Raj]

On Mon, Jun 12, 2017 at 11:23 AM, Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
> This looks great, except for one thing. What about external toolchains?
>
> We use Poky's compiler when building for ARM, but when building for
> MIPS we need to use our own, which is based on gcc 4.7.2 and not
> likely to be updated. With the suggested changes to security_flags.inc
> we will no longer be able to build with hardening enabled for MIPS...
>
> Regarding your changes:
> * Wouldn't it be better to define GCCPIE as:
>     GCCPIE ??= ""
>   in meta/recipes-devtools/gcc/gcc-configure-common.inc and as:
>     GCCPIE ?= "--enable-default-pie"
>   in meta/conf/distro/include/security_flags.inc? That way it is easy
>   to disable PIE by setting GCCPIE = "" in local.conf even if other
>   hardenings are enabled by including security_flags.inc.

that seems a fine idea, I will make this change locally.

> * It is probably a bad idea to change the definition of
>   SECURITY_NO_PIE_CFLAGS to:
>     SECURITY_NO_PIE_CFLAGS ?= "${SECURITY_CFLAGS}"
>   since it is most likely used to define SECURITY_CFLAGS in other
>   existing layers via the typical:
>     SECURITY_CFLAGS_pn-foo = "${SECURITY_NO_PIE_CFLAGS}"
>   and you will then end up with a circular definition...
>
> For backwards compatibility it might be an idea to do the following
> in security_flags.inc:
>
> GCCPIE ?= "--enable-default-pie"
>
> # SECURITY_PIE_CFLAGS is used to maintain backwards compatibility for
> # the definitions of SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS after
> # the introduction of GCCPIE.
> SECURITY_PIE_CFLAGS ?= "${@'' if '${GCCPIE}' else '-pie -fpie'}"
> SECURITY_CFLAGS ?= "-fstack-protector-strong ${SECURITY_PIE_CFLAGS} ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>
> That way the SECURITY_CFLAGS and SECURITY_NO_PIE_CFLAGS variables
> would keep their old values unless GCCPIE is set to something, which
> it is by default.

seems good yes, I will have run into this error once I plug in meta-oe
but was still building oe-core world.

>
> Enabling hardening but without PIE would then become:
>
> GCCPIE = ""
> SECURITY_PIE_CFLAGS = ""
>

agreed.

> //Peter
>
>> -----Original Message-----
>> From: Khem Raj [mailto:raj.khem@gmail.com]
>> Sent: den 12 juni 2017 16:47
>> To: Patrick Ohly <patrick.ohly@intel.com>
>> Cc: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; openembedded-
>> devel@lists.openembedded.org
>> Subject: Re: [oe] -pie in SECURITY_CFLAGS (was: Re: [meta-oe][PATCH
>> 1/3] meson: update Meson devtool to 0.40.1)
>>
>> 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@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@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.
>> >
>> >
>> >

Re: [meta-oe][PATCH 2/3] meson: fix build/host confusion for bbclass

[Linus Svensson]

On 06/05/2017 07:23 PM, Adam C. Foltzer wrote:
> Meson and Bitbake use different terminology for the build and host;
> this provides the correct build machine info to Meson.
What is the difference?

As far as I understand, bitbake and meson use the same terminology. 
meson is supposed to get the build machine info from the environment, 
not the cross file.

/Linus

Re: [meta-oe][PATCH v2] meson: add LDFLAGS to bbclass C/C++ link arguments

[Burton, Ross]

On 8 June 2017 at 18:34, Adam C. Foltzer <acfoltzer@galois.com> wrote:

> -cpu = '${TARGET_ARCH}'
> +cpu = '${TUNE_PKGARCH}'
>

This line was retracted in a later mail but the patch was merged.


>  SRC_URI = " \
>      git://github.com/mesonbuild/meson.git \
> -    file://native_bindir.patch \
>  "
>

Was this patch meant to be removed?  If so the file needs to be removed too.

Ross

Re: [meta-oe][PATCH 2/3] meson: fix build/host confusion for bbclass

[Burton, Ross]

On 16 June 2017 at 12:19, Linus Svensson <linus.svensson@axis.com> wrote:

> What is the difference?
>
> As far as I understand, bitbake and meson use the same terminology. meson
> is supposed to get the build machine info from the environment, not the
> cross file.
>

Linus is right.  Quoting the documentation:

autotools:
--build: In which system the program will be built.
--host: In which system the generated program will run.

Meson:
build machine is the computer that is doing the actual compiling
host machine is the machine on which the compiled binary will run

So changing host_machine to use BUILD_* variables is wrong.

Ross