public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Joshua Lock <joshua.g.lock@linux.intel.com>
To: "André Draszik" <git@andred.net>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/5] security_flags: pass ssp-buffer-size param to stack protector
Date: Mon, 22 Aug 2016 11:42:47 +0100	[thread overview]
Message-ID: <1471862567.5256.18.camel@linux.intel.com> (raw)
In-Reply-To: <1471852964.3713.7.camel@andred.net>

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


  reply	other threads:[~2016-08-22 10:42 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
2016-08-22  8:02       ` André Draszik
2016-08-22 10:42         ` Joshua Lock [this message]
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=1471862567.5256.18.camel@linux.intel.com \
    --to=joshua.g.lock@linux.intel.com \
    --cc=git@andred.net \
    --cc=openembedded-core@lists.openembedded.org \
    /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