[PATCH 0/5] security_flags: additions in line with common practice

[PATCH 0/5] security_flags: additions in line with common practice

[Joshua Lock]

This series tidies up the security_flags include to:
* remove an invalid option
* update the flags to be more in-line with the common options in use on major distros such as Ubuntu and Fedora

This series has been tested on qemuarm, qemuarm64 and qemux86-64 building core-image-minimal, core-image-sato, core-image-lsb, core-image-lsb-dev and core-image-lsb-sdk images for poky-lsb distro.

Regards,

Joshua

The following changes since commit d3e5c1d17f80b3dd7a6d85e07b5c0c516f09ae93:

  local.conf.sample: Disable ARM and PPC due to prelink test case failures (2016-08-19 10:23:31 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/secflags
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/secflags

Joshua Lock (5):
  security_flags: remove invalid linker option
  security_flags: pass ssp-buffer-size param to stack protector
  security_flags: link position independent executables
  security_flags: update comment header
  security_flags: ensure changes to SHARED_OBJECTS cause recompile

 meta/conf/distro/include/security_flags.inc | 333 ++++++++++++++++++++++++++--
 1 file changed, 320 insertions(+), 13 deletions(-)

-- 
2.7.4

[PATCH 1/5] security_flags: remove invalid linker option

[Joshua Lock]

-fstack-protector-* is a compiler option, not a linker option.

[YOCTO #9948]

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
---
 meta/conf/distro/include/security_flags.inc | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index 20f48de..77fade6 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -15,8 +15,8 @@ SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
 SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
 SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
 
-SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
-SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
+SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
+SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
 
 # powerpc does not get on with pie for reasons not looked into as yet
 SECURITY_CFLAGS_powerpc = "-fstack-protector-strong ${lcl_maybe_fortify}"
@@ -100,11 +100,6 @@ SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
 TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
 TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
 
-SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
-SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
-SECURITY_LDFLAGS_remove_pn-glibc-initial = "-fstack-protector-strong"
-SECURITY_LDFLAGS_remove_pn-uclibc = "-fstack-protector-strong"
-SECURITY_LDFLAGS_remove_pn-uclibc-initial = "-fstack-protector-strong"
 SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
 SECURITY_LDFLAGS_pn-xf86-video-intel = "${SECURITY_X_LDFLAGS}"
 SECURITY_LDFLAGS_pn-xf86-video-omapfb = "${SECURITY_X_LDFLAGS}"
-- 
2.7.4

[PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector

[Joshua Lock]

This tells the compiler to use a canary to protect any function which
declares a character array of 4 or more bytes on its stack, rather
than the default of 8 or more bytes.

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
---
 meta/conf/distro/include/security_flags.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index 77fade6..691cea1 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -12,8 +12,8 @@ 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"
 
-SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
-SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
+SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
+SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
 
 SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
 SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
-- 
2.7.4

[PATCH 3/5] security_flags: link position independent executables

[Joshua Lock]

Link non-shared objects with the -pie option to enable the kernel
to make use of Address Space Layout Randomisation (ASLR) and harden
against Return Oriented Programming (ROP) attacks.

As this linker option  isn't compatible with the -fPIC option used
to build shared libraries any recipe which produces shared objects
should have an override setting SHARED_OBJECTS to 1 to disable
the addition of -pie to the linker flags.

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
---
 meta/conf/distro/include/security_flags.inc | 314 +++++++++++++++++++++++++++-
 1 file changed, 311 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index 691cea1..698f4c2 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -9,14 +9,19 @@
 # -O0 which then results in a compiler warning.
 lcl_maybe_fortify = "${@base_conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=2',d)}"
 
+# shared libraries are already position independent and shouldn't be linked with
+# the -pie option. Override SHARED_OBJECTS (which defaults to 0) to 1 to prevent
+# linking with -pie
+pie_ld = "${@base_conditional('SHARED_OBJECTS','1','',',-pie',d)}"
+
 # Error on use of format strings that represent possible security problems
 SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
 
 SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
 SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
 
-SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
-SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
+SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
+SECURITY_X_LDFLAGS ?= "-Wl,-z,relro${pie_ld}"
 
 # powerpc does not get on with pie for reasons not looked into as yet
 SECURITY_CFLAGS_powerpc = "-fstack-protector-strong ${lcl_maybe_fortify}"
@@ -65,10 +70,14 @@ SECURITY_CFLAGS_pn-libglu = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libpcap = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libpcre = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-libproxy = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-lttng-ust = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-libusb1 = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-libusb-compat = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-mesa = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-openssl = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-opensp = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-ppp = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-ptest-runner = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python-pycurl = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python-smartpm = "${SECURITY_NO_PIE_CFLAGS}"
@@ -78,8 +87,8 @@ SECURITY_CFLAGS_pn-python3-pycairo = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-python3 = "${SECURITY_NO_PIE_CFLAGS}"
 # Revert RPM to using internally supported values
 SECURITY_CFLAGS_pn-rpm = "${lcl_maybe_fortify} -fstack-protector"
-SECURITY_CFLAGS_pn-syslinux = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-slang = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_CFLAGS_pn-syslinux = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-tcl = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-tiff = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_CFLAGS_pn-uclibc = ""
@@ -100,6 +109,305 @@ SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
 TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
 TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
 
+SHARED_OBJECTS ?= "0"
+SHARED_OBJECTS_pn-acl = "1"
+SHARED_OBJECTS_pn-alsa-lib = "1"
+SHARED_OBJECTS_pn-alsa-tools = "1"
+SHARED_OBJECTS_pn-apmd = "1"
+SHARED_OBJECTS_pn-apr = "1"
+SHARED_OBJECTS_pn-apr-util = "1"
+SHARED_OBJECTS_pn-apt = "1"
+SHARED_OBJECTS_pn-aspell = "1"
+SHARED_OBJECTS_pn-at = "1"
+SHARED_OBJECTS_pn-at-spi2-core = "1"
+SHARED_OBJECTS_pn-atk = "1"
+SHARED_OBJECTS_pn-attr = "1"
+SHARED_OBJECTS_pn-avahi = "1"
+SHARED_OBJECTS_pn-avahi-ui = "1"
+SHARED_OBJECTS_pn-lttng-tools_arm = "1"
+SHARED_OBJECTS_pn-base-passwd = "1"
+SHARED_OBJECTS_pb-bdwgc = "1"
+SHARED_OBJECTS_pn-beecrypt = "1"
+SHARED_OBJECTS_pn-binutils = "1"
+SHARED_OBJECTS_pn-blktrace = "1"
+SHARED_OBJECTS_pn-bzip2 = "1"
+SHARED_OBJECTS_pn-cairo = "1"
+SHARED_OBJECTS_pn-chkconfig = "1"
+SHARED_OBJECTS_pn-clutter-1.0 = "1"
+SHARED_OBJECTS_pn-clutter-gtk-1.0 = "1"
+SHARED_OBJECTS_pn-clutter-gst-3.0 = "1"
+SHARED_OBJECTS_pn-cogl-1.0 = "1"
+SHARED_OBJECTS_pn-consolekit = "1"
+SHARED_OBJECTS_pn-coreutils = "1"
+SHARED_OBJECTS_pn-cracklib = "1"
+SHARED_OBJECTS_pn-cups = "1"
+SHARED_OBJECTS_pn-curl = "1"
+SHARED_OBJECTS_pn-db = "1"
+SHARED_OBJECTS_pn-dbus = "1"
+SHARED_OBJECTS_pn-dbus-glib = "1"
+SHARED_OBJECTS_pn-dbus-test = "1"
+SHARED_OBJECTS_pn-diffstat = "1"
+SHARED_OBJECTS_pn-directfb = "1"
+SHARED_OBJECTS_pn-dropbear = "1"
+SHARED_OBJECTS_pn-e2fsprogs = "1"
+SHARED_OBJECTS_pn-ed = "1"
+SHARED_OBJECTS_pn-eglinfo-fb = "1"
+SHARED_OBJECTS_pn-eglinfo-x11 = "1"
+SHARED_OBJECTS_pn-elfutils = "1"
+SHARED_OBJECTS_pn-enchant = "1"
+SHARED_OBJECTS_pn-expat = "1"
+SHARED_OBJECTS_pn-expect = "1"
+SHARED_OBJECTS_pn-file = "1"
+SHARED_OBJECTS_pn-flac = "1"
+SHARED_OBJECTS_pn-flex = "1"
+SHARED_OBJECTS_pn-fontconfig = "1"
+SHARED_OBJECTS_pn-freetype = "1"
+SHARED_OBJECTS_pn-gcc = "1"
+SHARED_OBJECTS_pn-gcc-runtime = "1"
+SHARED_OBJECTS_pn-gcc-sanitizers = "1"
+SHARED_OBJECTS_pn-gconf = "1"
+SHARED_OBJECTS_pn-gcr = "1"
+SHARED_OBJECTS_pn-gdb = "1"
+SHARED_OBJECTS_pn-gdbm = "1"
+SHARED_OBJECTS_pn-gdk-pixbuf = "1"
+SHARED_OBJECTS_pn-gettext = "1"
+SHARED_OBJECTS_pn-ghostscript = "1"
+SHARED_OBJECTS_pn-glew = "1"
+SHARED_OBJECTS_pn-glib-2.0 = "1"
+SHARED_OBJECTS_pn-glibc = "1"
+SHARED_OBJECTS_pn-glibc-initial = "1"
+SHARED_OBJECTS_pn-gmp = "1"
+SHARED_OBJECTS_pn-gnome-desktop3 = "1"
+SHARED_OBJECTS_pn-gnome-desktop-testing = "1"
+SHARED_OBJECTS_pn-gpgme = "1"
+SHARED_OBJECTS_pn-gnutls = "1"
+SHARED_OBJECTS_pn-gst-plugins-bad = "1"
+SHARED_OBJECTS_pn-gst-plugins-gl = "1"
+SHARED_OBJECTS_pn-gstreamer1.0 = "1"
+SHARED_OBJECTS_pn-gstreamer1.0-plugins-bad = "1"
+SHARED_OBJECTS_pn-gstreamer1.0-plugins-base = "1"
+SHARED_OBJECTS_pn-gstreamer1.0-plugins-good = "1"
+SHARED_OBJECTS_pn-gstreamer1.0-rtsp-server = "1"
+SHARED_OBJECTS_pn-gtk+ = "1"
+SHARED_OBJECTS_pn-gtk+3 = "1"
+SHARED_OBJECTS_pn-harfbuzz = "1"
+SHARED_OBJECTS_pn-hdparm = "1"
+SHARED_OBJECTS_pn-iproute2 = "1"
+SHARED_OBJECTS_pn-iputils = "1"
+SHARED_OBJECTS_pn-iw = "1"
+SHARED_OBJECTS_pn-json-glib = "1"
+SHARED_OBJECTS_pn-kernelshark = "1"
+SHARED_OBJECTS_pn-kexec-tools = "1"
+SHARED_OBJECTS_pn-kmod = "1"
+SHARED_OBJECTS_pn-icu = "1"
+SHARED_OBJECTS_pn-iptables = "1"
+SHARED_OBJECTS_pn-jpeg = "1"
+SHARED_OBJECTS_pn-json-c = "1"
+SHARED_OBJECTS_pn-less = "1"
+SHARED_OBJECTS_pn-liba52 = "1"
+SHARED_OBJECTS_pn-libacpi = "1"
+SHARED_OBJECTS_pn-libaio = "1"
+SHARED_OBJECTS_pn-libarchive = "1"
+SHARED_OBJECTS_pn-libart-lgpl = "1"
+SHARED_OBJECTS_pn-libassuan = "1"
+SHARED_OBJECTS_pn-libcap = "1"
+SHARED_OBJECTS_pn-libcap-ng = "1"
+SHARED_OBJECTS_pn-libcgroup = "1"
+SHARED_OBJECTS_pn-libcheck = "1"
+SHARED_OBJECTS_pn-libcroco = "1"
+SHARED_OBJECTS_pn-libdaemon = "1"
+SHARED_OBJECTS_pn-libdmx = "1"
+SHARED_OBJECTS_pn-libdrm = "1"
+SHARED_OBJECTS_pn-libepoxy = "1"
+SHARED_OBJECTS_pn-libevdev = "1"
+SHARED_OBJECTS_pn-libevent = "1"
+SHARED_OBJECTS_pn-libexif = "1"
+SHARED_OBJECTS_pn-libfakekey = "1"
+SHARED_OBJECTS_pn-libffi = "1"
+SHARED_OBJECTS_pn-libfm = "1"
+SHARED_OBJECTS_pn-libfm-extra = "1"
+SHARED_OBJECTS_pn-libfontenc = "1"
+SHARED_OBJECTS_pn-libgcc = "1"
+SHARED_OBJECTS_pn-libgcrypt = "1"
+SHARED_OBJECTS_pn-libgpg-error= "1"
+SHARED_OBJECTS_pn-libglade = "1"
+SHARED_OBJECTS_pn-libglu = "1"
+SHARED_OBJECTS_pn-libgudev = "1"
+SHARED_OBJECTS_pn-libical = "1"
+SHARED_OBJECTS_pn-libice = "1"
+SHARED_OBJECTS_pn-libiconv = "1"
+SHARED_OBJECTS_pn-libid3tag = "1"
+SHARED_OBJECTS_pn-libidn = "1"
+SHARED_OBJECTS_pn-libinput = "1"
+SHARED_OBJECTS_pn-libjpeg-turbo = "1"
+SHARED_OBJECTS_pn-libksba = "1"
+SHARED_OBJECTS_pn-libmatchbox = "1"
+SHARED_OBJECTS_pn-libmc = "1"
+SHARED_OBJECTS_pn-libmpc = "1"
+SHARED_OBJECTS_pn-libnewt = "1"
+SHARED_OBJECTS_pn-libnewt-python = "1"
+SHARED_OBJECTS_pn-libnfsidmap = "1"
+SHARED_OBJECTS_pn-libnotify = "1"
+SHARED_OBJECTS_pn-libnl = "1"
+SHARED_OBJECTS_pn-libogg = "1"
+SHARED_OBJECTS_pn-libpam = "1"
+SHARED_OBJECTS_pn-libpcap = "1"
+SHARED_OBJECTS_pn-libpciaccess = "1"
+SHARED_OBJECTS_pn-libpcre = "1"
+SHARED_OBJECTS_pn-libpng = "1"
+SHARED_OBJECTS_pn-libproxy = "1"
+SHARED_OBJECTS_pn-librsvg = "1"
+SHARED_OBJECTS_pn-libsamplerate0 = "1"
+SHARED_OBJECTS_pn-libsecret = "1"
+SHARED_OBJECTS_pn-libsm = "1"
+SHARED_OBJECTS_pn-libsndfile1 = "1"
+SHARED_OBJECTS_pn-libsolv = "1"
+SHARED_OBJECTS_pn-libsoup-2.4 = "1"
+SHARED_OBJECTS_pn-libtasn1 = "1"
+SHARED_OBJECTS_pn-libtirpc = "1"
+SHARED_OBJECTS_pn-libtool = "1"
+SHARED_OBJECTS_pn-libunistring = "1"
+SHARED_OBJECTS_pn-libunwind = "1"
+SHARED_OBJECTS_pn-liburcu = "1"
+SHARED_OBJECTS_pn-libusb1 = "1"
+SHARED_OBJECTS_pn-libusb-compat = "1"
+SHARED_OBJECTS_pn-libuser = "1"
+SHARED_OBJECTS_pn-libvorbis = "1"
+SHARED_OBJECTS_pn-libwebp = "1"
+SHARED_OBJECTS_pn-libwnck3 = "1"
+SHARED_OBJECTS_pn-libx11 = "1"
+SHARED_OBJECTS_pn-libx11-diet = "1"
+SHARED_OBJECTS_pn-libxau = "1"
+SHARED_OBJECTS_pn-libxcalibrate = "1"
+SHARED_OBJECTS_pn-libxcb = "1"
+SHARED_OBJECTS_pn-libxcomposite = "1"
+SHARED_OBJECTS_pn-libxcursor = "1"
+SHARED_OBJECTS_pn-libxdamage = "1"
+SHARED_OBJECTS_pn-libxdmcp = "1"
+SHARED_OBJECTS_pn-libxext = "1"
+SHARED_OBJECTS_pn-libxfixes = "1"
+SHARED_OBJECTS_pn-libxfont = "1"
+SHARED_OBJECTS_pn-libxft = "1"
+SHARED_OBJECTS_pn-libxi = "1"
+SHARED_OBJECTS_pn-libxinerama = "1"
+SHARED_OBJECTS_pn-libxkbcommon = "1"
+SHARED_OBJECTS_pn-libxkbfile = "1"
+SHARED_OBJECTS_pn-libxml2 = "1"
+SHARED_OBJECTS_pn-libxmu = "1"
+SHARED_OBJECTS_pn-libxpm = "1"
+SHARED_OBJECTS_pn-libxrandr = "1"
+SHARED_OBJECTS_pn-libxrender = "1"
+SHARED_OBJECTS_pn-libxres = "1"
+SHARED_OBJECTS_pn-libxscrnsaver = "1"
+SHARED_OBJECTS_pn-libxshmfence = "1"
+SHARED_OBJECTS_pn-libxslt = "1"
+SHARED_OBJECTS_pn-libxt = "1"
+SHARED_OBJECTS_pn-libxtst = "1"
+SHARED_OBJECTS_pn-libxv = "1"
+SHARED_OBJECTS_pn-libxvmc = "1"
+SHARED_OBJECTS_pn-libxxf86dga = "1"
+SHARED_OBJECTS_pn-libxxf86misc = "1"
+SHARED_OBJECTS_pn-libxxf86vm = "1"
+SHARED_OBJECTS_pn-libyaml = "1"
+SHARED_OBJECTS_pn-lighttpd = "1"
+SHARED_OBJECTS_pn-logrotate = "1"
+SHARED_OBJECTS_pn-lsof = "1"
+SHARED_OBJECTS_pn-lttng-tools = "1"
+SHARED_OBJECTS_pn-lttng-ust = "1"
+SHARED_OBJECTS_pn-ltp = "1"
+SHARED_OBJECTS_pn-lzo = "1"
+SHARED_OBJECTS_pn-mailx = "1"
+SHARED_OBJECTS_pn-man = "1"
+SHARED_OBJECTS_pn-matchbox-panel-2 = "1"
+SHARED_OBJECTS_pn-menu-cache = "1"
+SHARED_OBJECTS_pn-mesa = "1"
+SHARED_OBJECTS_pn-mesa-gl = "1"
+SHARED_OBJECTS_pn-mpfr = "1"
+SHARED_OBJECTS_pn-mktemp = "1"
+SHARED_OBJECTS_pn-mtdev = "1"
+SHARED_OBJECTS_pn-musl = "1"
+SHARED_OBJECTS_pn-mx-1.0 = "1"
+SHARED_OBJECTS_pn-ncurses = "1"
+SHARED_OBJECTS_pn-neon = "1"
+SHARED_OBJECTS_pn-net-tools = "1"
+SHARED_OBJECTS_pn-nettle = "1"
+SHARED_OBJECTS_pn-npth = "1"
+SHARED_OBJECTS_pn-nspr = "1"
+SHARED_OBJECTS_pn-nss = "1"
+SHARED_OBJECTS_pn-openssl = "1"
+SHARED_OBJECTS_pn-opensp = "1"
+SHARED_OBJECTS_pn-opkg = "1"
+SHARED_OBJECTS_pn-orc = "1"
+SHARED_OBJECTS_pn-ossp-uuid = "1"
+SHARED_OBJECTS_pn-p11-kit = "1"
+SHARED_OBJECTS_pn-pango = "1"
+SHARED_OBJECTS_pn-parted = "1"
+SHARED_OBJECTS_pn-pciutils = "1"
+SHARED_OBJECTS_pn-perl = "1"
+SHARED_OBJECTS_pn-pixman = "1"
+SHARED_OBJECTS_pn-piglit = "1"
+SHARED_OBJECTS_pn-pigz = "1"
+SHARED_OBJECTS_pn-popt = "1"
+SHARED_OBJECTS_pn-ppp = "1"
+SHARED_OBJECTS_pn-procps = "1"
+SHARED_OBJECTS_pn-ptest-runner = "1"
+SHARED_OBJECTS_pn-pulseaudio = "1"
+SHARED_OBJECTS_pn-python = "1"
+SHARED_OBJECTS_pn-python-pycurl = "1"
+SHARED_OBJECTS_pn-python-smartpm = "1"
+SHARED_OBJECTS_pn-python-numpy = "1"
+SHARED_OBJECTS_pn-python3-numpy = "1"
+SHARED_OBJECTS_pn-python3-pycairo = "1"
+SHARED_OBJECTS_pn-python3 = "1"
+SHARED_OBJECTS_pn-readline = "1"
+SHARED_OBJECTS_pn-rpm = "1"
+SHARED_OBJECTS_pn-sbc = "1"
+SHARED_OBJECTS_pn-screen = "1"
+SHARED_OBJECTS_pn-serf = "1"
+SHARED_OBJECTS_pn-slang = "1"
+SHARED_OBJECTS_pn-speex = "1"
+SHARED_OBJECTS_pn-speexdsp = "1"
+SHARED_OBJECTS_pn-sqlite3 = "1"
+SHARED_OBJECTS_pn-startup-notification = "1"
+SHARED_OBJECTS_pn-subversion = "1"
+SHARED_OBJECTS_pn-sudo = "1"
+SHARED_OBJECTS_pn-sysfsutils = "1"
+SHARED_OBJECTS_pn-sysklogd = "1"
+SHARED_OBJECTS_pn-syslinux = "1"
+SHARED_OBJECTS_pn-sysprof = "1"
+SHARED_OBJECTS_pn-systemd = "1"
+SHARED_OBJECTS_pn-tcl = "1"
+SHARED_OBJECTS_pn-tcp-wrappers = "1"
+SHARED_OBJECTS_pn-tiff = "1"
+SHARED_OBJECTS_pn-trace-cmd = "1"
+SHARED_OBJECTS_pn-tslib = "1"
+SHARED_OBJECTS_pn-uclibc = "1"
+SHARED_OBJECTS_pn-uclibc-initial = "1"
+SHARED_OBJECTS_pn-unzip = "1"
+SHARED_OBJECTS_pn-util-linux = "1"
+SHARED_OBJECTS_pn-v86d = "1"
+SHARED_OBJECTS_pn-vala = "1"
+SHARED_OBJECTS_pn-vte = "1"
+SHARED_OBJECTS_pn-waffle = "1"
+SHARED_OBJECTS_pn-wayland = "1"
+SHARED_OBJECTS_pn-webkitgtk = "1"
+SHARED_OBJECTS_pn-wpa-supplicant = "1"
+SHARED_OBJECTS_pn-xcb-util = "1"
+SHARED_OBJECTS_pn-xcb-util-image = "1"
+SHARED_OBJECTS_pn-xcb-util-keysyms = "1"
+SHARED_OBJECTS_pn-xcb-util-renderutil = "1"
+SHARED_OBJECTS_pn-xcb-util-wm= "1"
+SHARED_OBJECTS_pn-xz = "1"
+SHARED_OBJECTS_pn-zip = "1"
+SHARED_OBJECTS_pn-zlib = "1"
+
+SECURITY_LDFLAGS_pn-grub = ""
+SECURITY_LDFLAGS_pn-grub-efi = ""
+SECURITY_LDFLAGS_pn-grub-efi-native = ""
+SECURITY_LDFLAGS_pn-grub-efi-x86-native = ""
+SECURITY_LDFLAGS_pn-grub-efi-i586-native = ""
+SECURITY_LDFLAGS_pn-grub-efi-x86-64-native = ""
+SECURITY_LDFLAGS_pn-valgrind = ""
 SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
 SECURITY_LDFLAGS_pn-xf86-video-intel = "${SECURITY_X_LDFLAGS}"
 SECURITY_LDFLAGS_pn-xf86-video-omapfb = "${SECURITY_X_LDFLAGS}"
-- 
2.7.4

[PATCH 4/5] security_flags: update comment header

[Joshua Lock]

Embelish a little on the utility of the extra compiler and linker
flags enabled by this include.

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
---
 meta/conf/distro/include/security_flags.inc | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index 698f4c2..295c733 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -1,6 +1,9 @@
-# Setup extra CFLAGS and LDFLAGS which have 'security' benefits. These 
-# don't work universally, there are recipes which can't use one, the other
-# or both so a blacklist is maintained here. The idea would be over
+# Setup extra CFLAGS and LDFLAGS which:
+# * add extra compilation checks for known security anti-patterns
+# * generate extra code to protect against various attacks
+# * harden the produced binaries to provide extra protection against attacks.
+# These don't work universally, there are recipes which can't use one, the
+# other or both so a blacklist is maintained here. The idea would be over
 # time to reduce this list to nothing.
 # From a Yocto Project perspective, this file is included and tested
 # in the DISTRO="poky-lsb" configuration.
-- 
2.7.4

[PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Joshua Lock]

Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so that
changing SHARED_OBJECTS causes do_compile to re-run.

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
---
 meta/conf/distro/include/security_flags.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index 295c733..901c841 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 -pie -fpi
 SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
 
 SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
+SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"
 SECURITY_X_LDFLAGS ?= "-Wl,-z,relro${pie_ld}"
 
 # powerpc does not get on with pie for reasons not looked into as yet
-- 
2.7.4

Re: [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Richard Purdie]

On Fri, 2016-08-19 at 16:34 +0100, Joshua Lock wrote:
> Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so that
> changing SHARED_OBJECTS causes do_compile to re-run.
> 
> Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> ---
>  meta/conf/distro/include/security_flags.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/distro/include/security_flags.inc
> b/meta/conf/distro/include/security_flags.inc
> index 295c733..901c841 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong -
> -param ssp-buffer-size=4 -pie -fpi
>  SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp
> -buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>  
>  SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
> +SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"

Surely you want:

pid_ld[vardeps] += "SHARED_OBJECTS"

?

Also, you mention SHARED_OBJECTS defaults to "0", where is that? I am a
little worried the variable name is also a bit generic? Setting this in
the following way:

SECURITY_SHARED_OBJECTS = "-fpie"
SECURITY_SHARED_OBJECTS_pn-XXX = ""

may be more in keeping with the way the rest of the file is written and
avoids games with base_conditional and vardeps?

I am also worried about trying to maintain a large list like this, the
idea was to reduce the number of exceptions, not build lists which will
ever increase :(. I can't see this scaling.

Cheers,

Richard

Re: [PATCH 1/5] security_flags: remove invalid linker option

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]


> On Aug 19, 2016, at 8:34 AM, Joshua Lock <joshua.g.lock@intel.com> wrote:
> 
> -fstack-protector-* is a compiler option, not a linker option.

IIRC There are packages
who do not use CFLAGS in linker cmdline which case this fails

what issues do you see with this option appearing in ldflags ?

This should be tested with world builds on both musl and glibc


> 
> [YOCTO #9948]
> 
> Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> ---
> meta/conf/distro/include/security_flags.inc | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
> index 20f48de..77fade6 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -15,8 +15,8 @@ SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
> SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> 
> -SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
> -SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
> +SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> +SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> 
> # powerpc does not get on with pie for reasons not looked into as yet
> SECURITY_CFLAGS_powerpc = "-fstack-protector-strong ${lcl_maybe_fortify}"
> @@ -100,11 +100,6 @@ SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
> TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
> TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
> 
> -SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-strong"
> -SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
> -SECURITY_LDFLAGS_remove_pn-glibc-initial = "-fstack-protector-strong"
> -SECURITY_LDFLAGS_remove_pn-uclibc = "-fstack-protector-strong"
> -SECURITY_LDFLAGS_remove_pn-uclibc-initial = "-fstack-protector-strong"
> SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
> SECURITY_LDFLAGS_pn-xf86-video-intel = "${SECURITY_X_LDFLAGS}"
> SECURITY_LDFLAGS_pn-xf86-video-omapfb = "${SECURITY_X_LDFLAGS}"
> --
> 2.7.4
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]


> On Aug 19, 2016, at 8:34 AM, Joshua Lock <joshua.g.lock@intel.com> wrote:
> 
> This tells the compiler to use a canary to protect any function which
> declares a character array of 4 or more bytes on its stack, rather
> than the default of 8 or more bytes.

Thats fine, however, it slows down the code, strong option was a compromise
otherwise we could just use fstack-protector-all

> 
> Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> ---
> meta/conf/distro/include/security_flags.inc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
> index 77fade6..691cea1 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -12,8 +12,8 @@ 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"
> 
> -SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> +SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> +SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> 
> SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> --
> 2.7.4
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]


> On Aug 19, 2016, at 9:02 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Fri, 2016-08-19 at 16:34 +0100, Joshua Lock wrote:
>> Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so that
>> changing SHARED_OBJECTS causes do_compile to re-run.
>> 
>> Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
>> ---
>> meta/conf/distro/include/security_flags.inc | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/meta/conf/distro/include/security_flags.inc
>> b/meta/conf/distro/include/security_flags.inc
>> index 295c733..901c841 100644
>> --- a/meta/conf/distro/include/security_flags.inc
>> +++ b/meta/conf/distro/include/security_flags.inc
>> @@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong -
>> -param ssp-buffer-size=4 -pie -fpi
>> SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp
>> -buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>> 
>> SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
>> +SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"
> 
> Surely you want:
> 
> pid_ld[vardeps] += "SHARED_OBJECTS"
> 
> ?
> 
> Also, you mention SHARED_OBJECTS defaults to "0", where is that? I am a
> little worried the variable name is also a bit generic? Setting this in
> the following way:
> 
> SECURITY_SHARED_OBJECTS = "-fpie"
> SECURITY_SHARED_OBJECTS_pn-XXX = ""
> 
> may be more in keeping with the way the rest of the file is written and
> avoids games with base_conditional and vardeps?
> 
> I am also worried about trying to maintain a large list like this, the
> idea was to reduce the number of exceptions, not build lists which will
> ever increase :(. I can't see this scaling.

I agree with you here. I am mulling over a proposal for architecture change in 2.3
where we harden the toolchain by default and then dont have to keep the securiry
band-aid. Opinion?

> 
> Cheers,
> 
> Richard
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Joshua G Lock]

On Fri, 2016-08-19 at 17:02 +0100, Richard Purdie wrote:
> On Fri, 2016-08-19 at 16:34 +0100, Joshua Lock wrote:
> > 
> > Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so that
> > changing SHARED_OBJECTS causes do_compile to re-run.
> > 
> > Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> > ---
> >  meta/conf/distro/include/security_flags.inc | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/conf/distro/include/security_flags.inc
> > b/meta/conf/distro/include/security_flags.inc
> > index 295c733..901c841 100644
> > --- a/meta/conf/distro/include/security_flags.inc
> > +++ b/meta/conf/distro/include/security_flags.inc
> > @@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong -
> > -param ssp-buffer-size=4 -pie -fpi
> >  SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp
> > -buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> >  
> >  SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
> > +SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"
> 
> Surely you want:
> 
> pid_ld[vardeps] += "SHARED_OBJECTS"
> 
> ?
> 
> Also, you mention SHARED_OBJECTS defaults to "0", where is that?

At the top of the exceptions list in this patch.

>  I am a
> little worried the variable name is also a bit generic? Setting this
> in
> the following way:
> 
> SECURITY_SHARED_OBJECTS = "-fpie"
> SECURITY_SHARED_OBJECTS_pn-XXX = ""
> 
> may be more in keeping with the way the rest of the file is written
> and
> avoids games with base_conditional and vardeps?

Indeed, much cleaner.

> I am also worried about trying to maintain a large list like this,
> the
> idea was to reduce the number of exceptions, not build lists which
> will
> ever increase :(. I can't see this scaling.

Nor can I, to be honest. When I started down this path I hadn't quite
realised how large the exception list would be, however as I'd done the
work I wanted to at least get some feedback on it.
I did wonder about an inheritable class to set the variable, but it
didn't seem clean to require that class be inherited when the
security_flags aren't on by default. I should probably have tagged this
patch RFC…

Regards,

Joshua

Re: [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile

[Joshua G Lock]

On Fri, 2016-08-19 at 10:11 -0700, Khem Raj wrote:
> > 
> > On Aug 19, 2016, at 9:02 AM, Richard Purdie <richard.purdie@linuxfo
> > undation.org> wrote:
> > 
> > On Fri, 2016-08-19 at 16:34 +0100, Joshua Lock wrote:
> > > 
> > > Add the SHARED_OBJECTS variable to SECURITY_LDFLAGS vardeps so
> > > that
> > > changing SHARED_OBJECTS causes do_compile to re-run.
> > > 
> > > Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> > > ---
> > > meta/conf/distro/include/security_flags.inc | 1 +
> > > 1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/meta/conf/distro/include/security_flags.inc
> > > b/meta/conf/distro/include/security_flags.inc
> > > index 295c733..901c841 100644
> > > --- a/meta/conf/distro/include/security_flags.inc
> > > +++ b/meta/conf/distro/include/security_flags.inc
> > > @@ -24,6 +24,7 @@ SECURITY_CFLAGS ?= "-fstack-protector-strong -
> > > -param ssp-buffer-size=4 -pie -fpi
> > > SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp
> > > -buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > > 
> > > SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now${pie_ld}"
> > > +SECURITY_LDFLAGS[vardeps] += "SHARED_OBJECTS"
> > 
> > Surely you want:
> > 
> > pid_ld[vardeps] += "SHARED_OBJECTS"
> > 
> > ?
> > 
> > Also, you mention SHARED_OBJECTS defaults to "0", where is that? I
> > am a
> > little worried the variable name is also a bit generic? Setting
> > this in
> > the following way:
> > 
> > SECURITY_SHARED_OBJECTS = "-fpie"
> > SECURITY_SHARED_OBJECTS_pn-XXX = ""
> > 
> > may be more in keeping with the way the rest of the file is written
> > and
> > avoids games with base_conditional and vardeps?
> > 
> > I am also worried about trying to maintain a large list like this,
> > the
> > idea was to reduce the number of exceptions, not build lists which
> > will
> > ever increase :(. I can't see this scaling.
> 
> I agree with you here. I am mulling over a proposal for architecture
> change in 2.3
> where we harden the toolchain by default and then dont have to keep
> the securiry
> band-aid. Opinion?

It is my intention to make a proposal in 2.3 that we provide more
hardening by default. I'm in favour.

Regards,

Joshua

Re: [PATCH 1/5] security_flags: remove invalid linker option

[Joshua G Lock]

On Fri, 2016-08-19 at 10:05 -0700, Khem Raj wrote:
> > 
> > On Aug 19, 2016, at 8:34 AM, Joshua Lock <joshua.g.lock@intel.com>
> > wrote:
> > 
> > -fstack-protector-* is a compiler option, not a linker option.
> 
> IIRC There are packages
> who do not use CFLAGS in linker cmdline which case this fails
> 
> what issues do you see with this option appearing in ldflags ?
> 
> This should be tested with world builds on both musl and glibc

I wasn't sure why it appeared in ldflags, none of the (admittedly only
glibc) builds I did seemed to have any related failures.

I'll drop this patch and add a comment as to the intent of including
that in ldflags.

Thanks,

Joshua

> > 
> > 
> > [YOCTO #9948]
> > 
> > Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> > ---
> > meta/conf/distro/include/security_flags.inc | 9 ++-------
> > 1 file changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/meta/conf/distro/include/security_flags.inc
> > b/meta/conf/distro/include/security_flags.inc
> > index 20f48de..77fade6 100644
> > --- a/meta/conf/distro/include/security_flags.inc
> > +++ b/meta/conf/distro/include/security_flags.inc
> > @@ -15,8 +15,8 @@ SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-
> > security -Werror=format-security"
> > SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > 
> > -SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
> > -SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
> > +SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> > +SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> > 
> > # powerpc does not get on with pie for reasons not looked into as
> > yet
> > SECURITY_CFLAGS_powerpc = "-fstack-protector-strong
> > ${lcl_maybe_fortify}"
> > @@ -100,11 +100,6 @@ SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
> > TARGET_CFLAGS_append_class-target = " ${SECURITY_CFLAGS}"
> > TARGET_LDFLAGS_append_class-target = " ${SECURITY_LDFLAGS}"
> > 
> > -SECURITY_LDFLAGS_remove_pn-gcc-runtime = "-fstack-protector-
> > strong"
> > -SECURITY_LDFLAGS_remove_pn-glibc = "-fstack-protector-strong"
> > -SECURITY_LDFLAGS_remove_pn-glibc-initial = "-fstack-protector-
> > strong"
> > -SECURITY_LDFLAGS_remove_pn-uclibc = "-fstack-protector-strong"
> > -SECURITY_LDFLAGS_remove_pn-uclibc-initial = "-fstack-protector-
> > strong"
> > SECURITY_LDFLAGS_pn-xf86-video-fbdev = "${SECURITY_X_LDFLAGS}"
> > SECURITY_LDFLAGS_pn-xf86-video-intel = "${SECURITY_X_LDFLAGS}"
> > SECURITY_LDFLAGS_pn-xf86-video-omapfb = "${SECURITY_X_LDFLAGS}"
> > --
> > 2.7.4
> > 
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 

Re: [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector

[Joshua G Lock]

On Fri, 2016-08-19 at 10:07 -0700, Khem Raj wrote:
> > 
> > On Aug 19, 2016, at 8:34 AM, Joshua Lock <joshua.g.lock@intel.com>
> > wrote:
> > 
> > This tells the compiler to use a canary to protect any function
> > which
> > declares a character array of 4 or more bytes on its stack, rather
> > than the default of 8 or more bytes.
> 
> Thats fine, however, it slows down the code, strong option was a
> compromise
> otherwise we could just use fstack-protector-all

It's my understanding that the ssp-buffer-size parameter changes the
size of buffer the base, fstack-protector, protections affect and that
the performance impact is less significant than adding protections to
all functions via stack-protector-all?

FWIW, the related options in Fedora and Ubuntu:

* Ubuntu: -fstack-protector --param=ssp-buffer-size=4 (default in
hardened builds)
* Fedora: -fstack-protector-strong --param=ssp-buffer-size=4 (default
in all builds)

Regards,

Joshua

> > 
> > 
> > Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> > ---
> > meta/conf/distro/include/security_flags.inc | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/conf/distro/include/security_flags.inc
> > b/meta/conf/distro/include/security_flags.inc
> > index 77fade6..691cea1 100644
> > --- a/meta/conf/distro/include/security_flags.inc
> > +++ b/meta/conf/distro/include/security_flags.inc
> > @@ -12,8 +12,8 @@ lcl_maybe_fortify = "${@base_conditional('DEBUG_B
> > UILD','1','','-D_FORTIFY_SOURCE
> > # Error on use of format strings that represent possible security
> > problems
> > SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
> > -Werror=format-security"
> > 
> > -SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
> > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > +SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-
> > size=4 -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > +SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-
> > buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > 
> > SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> > SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> > --
> > 2.7.4
> > 
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 

Re: [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector

[André Draszik]

On Fr, 2016-08-19 at 19:46 +0100, Joshua G Lock wrote:
> On Fri, 2016-08-19 at 10:07 -0700, Khem Raj wrote:
> > 
> > > 
> > > 
> > > On Aug 19, 2016, at 8:34 AM, Joshua Lock <joshua.g.lock@intel.com>
> > > wrote:
> > > 
> > > This tells the compiler to use a canary to protect any function
> > > which
> > > declares a character array of 4 or more bytes on its stack, rather
> > > than the default of 8 or more bytes.
> > 
> > Thats fine, however, it slows down the code, strong option was a
> > compromise
> > otherwise we could just use fstack-protector-all
> 
> It's my understanding that the ssp-buffer-size parameter changes the
> size of buffer the base, fstack-protector, protections affect and that
> the performance impact is less significant than adding protections to
> all functions via stack-protector-all?

I understand it as follows instead:

--param=ssp-buffer-size=X only makes sense together with -fstack-protector, as -fstack-protector can to be configured for the minimum size of arrays to protect (8 by default, if --param=ssp-buffer-size= is not given).

--param=ssp-buffer-size=X does not make sense with -fstack-protector-strong as this version protects arrays of *any* size anyway.

https://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html
  -> This also has the design doc towards the end.
https://lwn.net/Articles/584225/

So I don't think this patch is needed at all...


> FWIW, the related options in Fedora and Ubuntu:
> 
> * Ubuntu: -fstack-protector --param=ssp-buffer-size=4 (default in
> hardened builds)
> * Fedora: -fstack-protector-strong --param=ssp-buffer-size=4 (default
> in all builds)

Debian (sid) uses -fstack-protector-strong (without ssp-buffer-size).



Cheers,
Andre'


> 
> Regards,
> 
> Joshua
> 
> > 
> > > 
> > > 
> > > 
> > > Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
> > > ---
> > > meta/conf/distro/include/security_flags.inc | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/meta/conf/distro/include/security_flags.inc
> > > b/meta/conf/distro/include/security_flags.inc
> > > index 77fade6..691cea1 100644
> > > --- a/meta/conf/distro/include/security_flags.inc
> > > +++ b/meta/conf/distro/include/security_flags.inc
> > > @@ -12,8 +12,8 @@ lcl_maybe_fortify = "${@base_conditional('DEBUG_B
> > > UILD','1','','-D_FORTIFY_SOURCE
> > > # Error on use of format strings that represent possible security
> > > problems
> > > SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
> > > -Werror=format-security"
> > > 
> > > -SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
> > > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > > -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
> > > ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > > +SECURITY_CFLAGS ?= "-fstack-protector-strong --param ssp-buffer-
> > > size=4 -pie -fpie ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > > +SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong --param ssp-
> > > buffer-size=4 ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
> > > 
> > > SECURITY_LDFLAGS ?= "-Wl,-z,relro,-z,now"
> > > SECURITY_X_LDFLAGS ?= "-Wl,-z,relro"
> > > --
> > > 2.7.4
> > > 
> > > --
> > > _______________________________________________
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > 

Re: [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector

[Joshua Lock]

On Mon, 2016-08-22 at 09:02 +0100, André Draszik wrote:
> On Fr, 2016-08-19 at 19:46 +0100, Joshua G Lock wrote:
> > 
> > On Fri, 2016-08-19 at 10:07 -0700, Khem Raj wrote:
> > > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > On Aug 19, 2016, at 8:34 AM, Joshua Lock <joshua.g.lock@intel.c
> > > > om>
> > > > wrote:
> > > > 
> > > > This tells the compiler to use a canary to protect any function
> > > > which
> > > > declares a character array of 4 or more bytes on its stack,
> > > > rather
> > > > than the default of 8 or more bytes.
> > > 
> > > Thats fine, however, it slows down the code, strong option was a
> > > compromise
> > > otherwise we could just use fstack-protector-all
> > 
> > It's my understanding that the ssp-buffer-size parameter changes
> > the
> > size of buffer the base, fstack-protector, protections affect and
> > that
> > the performance impact is less significant than adding protections
> > to
> > all functions via stack-protector-all?
> 
> I understand it as follows instead:
> 
> --param=ssp-buffer-size=X only makes sense together with -fstack-
> protector, as -fstack-protector can to be configured for the minimum
> size of arrays to protect (8 by default, if --param=ssp-buffer-size=
> is not given).
> 
> --param=ssp-buffer-size=X does not make sense with -fstack-protector-
> strong as this version protects arrays of *any* size anyway.
> 
> https://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html
>   -> This also has the design doc towards the end.
> https://lwn.net/Articles/584225/
> 
> So I don't think this patch is needed at all...

Thanks for the link, having read the patch and design doc I'm inclined
to agree.

> > 
> > FWIW, the related options in Fedora and Ubuntu:
> > 
> > * Ubuntu: -fstack-protector --param=ssp-buffer-size=4 (default in
> > hardened builds)
> > * Fedora: -fstack-protector-strong --param=ssp-buffer-size=4
> > (default
> > in all builds)
> 
> Debian (sid) uses -fstack-protector-strong (without ssp-buffer-size).
> 

Thanks, I couldn't find a Debian system on Friday evening.

Regards,

Joshua