All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua G Lock <joshua.g.lock@linux.intel.com>
To: Khem Raj <raj.khem@gmail.com>,
	Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 5/5] security_flags: ensure changes to SHARED_OBJECTS cause recompile
Date: Fri, 19 Aug 2016 19:26:56 +0100	[thread overview]
Message-ID: <1471631216.5679.10.camel@linux.intel.com> (raw)
In-Reply-To: <3E96D261-8098-4FC3-9437-15613450DD05@gmail.com>

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


  reply	other threads:[~2016-08-19 18:26 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
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 [this message]
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=1471631216.5679.10.camel@linux.intel.com \
    --to=joshua.g.lock@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=richard.purdie@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.