public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Joshua G Lock <joshua.g.lock@linux.intel.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector
Date: Fri, 19 Aug 2016 19:46:39 +0100	[thread overview]
Message-ID: <1471632399.5679.22.camel@linux.intel.com> (raw)
In-Reply-To: <9D776326-1F02-4F8E-B61C-DF3971141312@gmail.com>

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
> 


  reply	other threads:[~2016-08-19 18:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19 15:34 [PATCH 0/5] security_flags: additions in line with common practice Joshua Lock
2016-08-19 15:34 ` [PATCH 1/5] security_flags: remove invalid linker option Joshua Lock
2016-08-19 17:05   ` Khem Raj
2016-08-19 18:29     ` Joshua G Lock
2016-08-19 15:34 ` [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector Joshua Lock
2016-08-19 17:07   ` Khem Raj
2016-08-19 18:46     ` Joshua G Lock [this message]
2016-08-22  8:02       ` André Draszik
2016-08-22 10:42         ` Joshua Lock
2016-08-19 15:34 ` [PATCH 3/5] security_flags: link position independent executables Joshua Lock
2016-08-19 15:34 ` [PATCH 4/5] security_flags: update comment header Joshua Lock
2016-08-19 15:34 ` [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile Joshua Lock
2016-08-19 16:02   ` Richard Purdie
2016-08-19 17:11     ` Khem Raj
2016-08-19 18:26       ` Joshua G Lock
2016-08-19 18:26     ` Joshua G Lock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1471632399.5679.22.camel@linux.intel.com \
    --to=joshua.g.lock@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox