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
>
next prev parent 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