FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 09-07-2011, 09:55 AM
Raphael Hertzog
 
Default Hardening patch

Hi,

On Wed, 07 Sep 2011, Raphael Hertzog wrote:
> I'll also try to push today or tomorrow the code enabling hardening
> build flags as Kees sent me his documentation patch.

Here's what I'm going to push in case anyone feels like reviewing it
quickly (I'm waiting some final feedback from Kees).

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
 
Old 09-07-2011, 07:19 PM
Kees Cook
 
Default Hardening patch

On Wed, Sep 07, 2011 at 11:55:19AM +0200, Raphael Hertzog wrote:
> On Wed, 07 Sep 2011, Raphael Hertzog wrote:
> > I'll also try to push today or tomorrow the code enabling hardening
> > build flags as Kees sent me his documentation patch.
>
> Here's what I'm going to push in case anyone feels like reviewing it
> quickly (I'm waiting some final feedback from Kees).

Looks good, with a small change below. (Did I miss an email? What final
feedback was wanted?)

> diff --git a/man/dpkg-buildflags.1 b/man/dpkg-buildflags.1
> index b8dcd43..74bddad 100644
> --- a/man/dpkg-buildflags.1
> +++ b/man/dpkg-buildflags.1
...
> +gain ASLR. When this happens, ROP (Return Oriented Programming) attacks
> +are much harder since there are no static locations to bounce off of
> +during a memory corruption attack.
> +.TP
> +.PP
> +This is not compatible with fB-fPICfP so care must be taken when
> +building shared objects.
> +.TP
> +.PP

These TP/PP's should probably just be a blank line? My attempts at an
indented paragraph break don't actually seem to work right.

> +Additionally, since PIE is implemented via a general register, some
> +architectures (most notably i386) can see performance losses of up to
> +15% in very text-segment-heavy application workloads; most workloads

Thanks!

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110907191954.GG31645@outflux.net">http://lists.debian.org/20110907191954.GG31645@outflux.net
 
Old 09-07-2011, 08:37 PM
Guillem Jover
 
Default Hardening patch

On Wed, 2011-09-07 at 11:55:19 +0200, Raphael Hertzog wrote:
> Here's what I'm going to push in case anyone feels like reviewing it
> quickly (I'm waiting some final feedback from Kees).

Here it is.

> >From 8f1c8a783b35486c70f48969679090d77278665c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>
> Date: Wed, 27 Jul 2011 22:10:49 +0200
> Subject: [PATCH 2/3] dpkg-buildflags: emit hardening build flags by default
>
> All the hardening build flags supported by hardening-includes
> are supported except that PIE is not enabled by default (just like
> the corresponding gcc patch doesn't enable it by default).
>
> Inspired by the work of Kees Cook <kees@debian.org>.
> ---
> scripts/Dpkg/BuildFlags.pm | 89 ++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 89 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/Dpkg/BuildFlags.pm b/scripts/Dpkg/BuildFlags.pm
> index 9bc473a..5479af0 100644
> --- a/scripts/Dpkg/BuildFlags.pm
> +++ b/scripts/Dpkg/BuildFlags.pm
> @@ -84,9 +89,93 @@ sub load_vendor_defaults {
> FFLAGS => 'vendor',
> LDFLAGS => 'vendor',
> };
> + $self->add_hardening_flags();
> run_vendor_hook("update-buildflags", $self);
> }

This seems too compiler, system and distribution specific to be set by
default for all BuildFlags users, I think it would make more sense to
split it into a different module, and enable it from the Debian vendor
hook, so that Ubuntu inherits it too.

> +=item $bf->add_hardening_flags()
> +
> +Add hardening build flags to the current set of flags. It's always called
> +by load_vendor_defaults().
> +
> +=cut
> +
> +sub add_hardening_flags {
> + my ($self) = @_;
> + my $arch = get_host_arch();
> + my ($abi, $os, $cpu) = debarch_to_debtriplet($arch);
> +
> + # Decide what's enabled
> + my %use_feature = (
> + "pie" => 0,
> + "stackprotector" => 1,
> + "fortify" => 1,
> + "format" => 1,
> + "relro" => 1,
> + "bindnow" => 1
> + );
> + my $opts = Dpkg::BuildOptions->new(envvar => "DEB_BUILD_MAINT_OPTIONS");
> + foreach my $feature (split(",", $opts->get("hardening") // "")) {
> + $feature = lc($feature);
> + if ($feature =~ s/^([+-])//) {
> + my $value = ($1 eq "+") ? 1 : 0;
> + if ($feature eq "all") {
> + $use_feature{$_} = $value foreach keys %use_feature;
> + } else {
> + if (exists $use_feature{$feature}) {
> + $use_feature{$feature} = $value;
> + } else {
> + warning(_g("unknown hardening feature: %s"), $feature);
> + }
> + }
> + } else {
> + warning(_g("incorrect value in hardening option of " .
> + "DEB_BUILD_MAINT_OPTIONS: %s"), $feature);
> + }
> + }

How were you envisioning vendors to change the defaults?

Also I'm not sure now if this has been brought up before, but the
bindnow option might have noticable startup speed impact depending
on the amount of symbols and shared objects to resolve and load.
The other options seem sane in general.

> >From ccc609c3ff08dc0b1bdaadc432a23493664dfa6e Mon Sep 17 00:00:00 2001
> From: Kees Cook <kees@debian.org>
> Date: Mon, 5 Sep 2011 23:34:49 -0700
> Subject: [PATCH 3/3] dpkg-buildflags(1): add initial hardening documentation
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Document the various hardening options that can be enabled/disabled
> via DEB_BUILD_MAINT_OPTIONS.
>
> Improved-by: Raphal Hertzog <hertzog@debian.org>
> Signed-off-by: Kees Cook <kees@debian.org>
> Signed-off-by: Raphal Hertzog <hertzog@debian.org>

All minus signs that can end up being copy&pasted into a runnable
command, etc. need to be escaped as in - so that man does not turn
them into hyphens.

reagards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110907203713.GA1768@gaara.hadrons.org">http://lists.debian.org/20110907203713.GA1768@gaara.hadrons.org
 
Old 09-07-2011, 08:46 PM
Kees Cook
 
Default Hardening patch

Hi,

On Wed, Sep 07, 2011 at 10:37:13PM +0200, Guillem Jover wrote:
> Also I'm not sure now if this has been brought up before, but the
> bindnow option might have noticable startup speed impact depending
> on the amount of symbols and shared objects to resolve and load.
> The other options seem sane in general.

This is, thankfully, no longer the case now that the linker uses string
hashes for symbol resolution. I could not measure a difference in load
times (any delta seemed lost in the noise) even for giant (firefox,
openoffice.org) applications.

If anyone can show otherwise, I would be very interested in seeing the
results. AFAICT, bindnow is entirely a win.

> All minus signs that can end up being copy&pasted into a runnable
> command, etc. need to be escaped as in - so that man does not turn
> them into hyphens.

Ah, yes, good catch. Thanks!

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110907204621.GM31645@outflux.net">http://lists.debian.org/20110907204621.GM31645@outflux.net
 
Old 09-08-2011, 04:01 AM
Guillem Jover
 
Default Hardening patch

On Wed, 2011-09-07 at 13:46:21 -0700, Kees Cook wrote:
> On Wed, Sep 07, 2011 at 10:37:13PM +0200, Guillem Jover wrote:
> > Also I'm not sure now if this has been brought up before, but the
> > bindnow option might have noticable startup speed impact depending
> > on the amount of symbols and shared objects to resolve and load.
> > The other options seem sane in general.
>
> This is, thankfully, no longer the case now that the linker uses string
> hashes for symbol resolution. I could not measure a difference in load
> times (any delta seemed lost in the noise) even for giant (firefox,
> openoffice.org) applications.

Ah, you mean the ELF GNU hash (instead of the old SYSV hash), right.

> If anyone can show otherwise, I would be very interested in seeing the
> results. AFAICT, bindnow is entirely a win.

Did you try thoses tests only on fast architectures like i386 and amd64,
or also on slower ones like armel? If there's a significant impact I'd
expect to find it on those slower ones, which are precisely the ones
that would suffer most from it.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110908040106.GA8388@gaara.hadrons.org">http://lists.debian.org/20110908040106.GA8388@gaara.hadrons.org
 
Old 09-08-2011, 06:59 AM
Raphael Hertzog
 
Default Hardening patch

Hi,

On Wed, 07 Sep 2011, Guillem Jover wrote:
> > --- a/scripts/Dpkg/BuildFlags.pm
> > +++ b/scripts/Dpkg/BuildFlags.pm
> > @@ -84,9 +89,93 @@ sub load_vendor_defaults {
> > FFLAGS => 'vendor',
> > LDFLAGS => 'vendor',
> > };
> > + $self->add_hardening_flags();
> > run_vendor_hook("update-buildflags", $self);
> > }
>
> This seems too compiler, system and distribution specific to be set by
> default for all BuildFlags users, I think it would make more sense to
> split it into a different module, and enable it from the Debian vendor
> hook, so that Ubuntu inherits it too.

Good remark, creating a new module seemed overkill but I moved the logic
to Dpkg::Vendor:ebian (and adjusted Dpkg::Vendor::Ubuntu to properly
inherit from it).

If we ever end up supporting multiple compiler/libc each with their own
hardening build flags, then a new module might be a good idea. For now,
this will do.

> > Document the various hardening options that can be enabled/disabled
> > via DEB_BUILD_MAINT_OPTIONS.
>
> All minus signs that can end up being copy&pasted into a runnable
> command, etc. need to be escaped as in - so that man does not turn
> them into hyphens.

Yeah, I noticed that yesterday too, they were already fixed in an
updated copy of pu/build-flags as well as a few other details.

New patches attached.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
 
Old 09-11-2011, 12:14 AM
Kurt Roeckx
 
Default Hardening patch

On Wed, Sep 07, 2011 at 01:46:21PM -0700, Kees Cook wrote:
> Hi,
>
> On Wed, Sep 07, 2011 at 10:37:13PM +0200, Guillem Jover wrote:
> > Also I'm not sure now if this has been brought up before, but the
> > bindnow option might have noticable startup speed impact depending
> > on the amount of symbols and shared objects to resolve and load.
> > The other options seem sane in general.
>
> This is, thankfully, no longer the case now that the linker uses string
> hashes for symbol resolution. I could not measure a difference in load
> times (any delta seemed lost in the noise) even for giant (firefox,
> openoffice.org) applications.

It was my understanding that for iceweasel the biggest cost of
starting up is in fact the dynamic linker resolving all the
relocations. I currently still see this in libxul.so:
Relocation section '.rel.dyn' at offset 0x2b480 contains 180767 entries:
Relocation section '.rel.plt' at offset 0x18c578 contains 2853 entries:

Not to mention all the other libraries that get linked in.

Does anybody know if I set bindnow on an executable that it has effect
on all libraries that get loaded, or only on the directly linked
libraries?

Did you try this after a reboot, or was everything already cached?

What behaviour do you get for shared libraries that have undefined
symbols? I assume they'll break?


Kurt


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110911001409.GA27224@roeckx.be">http://lists.debian.org/20110911001409.GA27224@roeckx.be
 
Old 09-11-2011, 02:16 AM
Kees Cook
 
Default Hardening patch

Hi Kurt,

On Sun, Sep 11, 2011 at 02:14:09AM +0200, Kurt Roeckx wrote:
> On Wed, Sep 07, 2011 at 01:46:21PM -0700, Kees Cook wrote:
> > On Wed, Sep 07, 2011 at 10:37:13PM +0200, Guillem Jover wrote:
> > > Also I'm not sure now if this has been brought up before, but the
> > > bindnow option might have noticable startup speed impact depending
> > > on the amount of symbols and shared objects to resolve and load.
> > > The other options seem sane in general.
> >
> > This is, thankfully, no longer the case now that the linker uses string
> > hashes for symbol resolution. I could not measure a difference in load
> > times (any delta seemed lost in the noise) even for giant (firefox,
> > openoffice.org) applications.
>
> It was my understanding that for iceweasel the biggest cost of
> starting up is in fact the dynamic linker resolving all the
> relocations. I currently still see this in libxul.so:
> Relocation section '.rel.dyn' at offset 0x2b480 contains 180767 entries:
> Relocation section '.rel.plt' at offset 0x18c578 contains 2853 entries:
>
> Not to mention all the other libraries that get linked in.
>
> Does anybody know if I set bindnow on an executable that it has effect
> on all libraries that get loaded, or only on the directly linked
> libraries?
>
> Did you try this after a reboot, or was everything already cached?
>
> What behaviour do you get for shared libraries that have undefined
> symbols? I assume they'll break?

I did my tests after flushing disk caches.

# echo 3 > /proc/sys/vm/drop_caches
$ LD_DEBUG=statistics MOZ_NO_REMOTE=1 firefox -ProfileManager
...
12680:
12680: runtime linker statistics:
12680: total startup time in dynamic loader: 210245310 clock cycles
12680: time needed for relocation: 2091312 clock cycles (.9%)
12680: number of relocations: 1283
12680: number of relocations from cache: 1000
12680: number of relative relocations: 1850
12680: time needed to load objects: 207754479 clock cycles (98.8%)
...

# echo 3 > /proc/sys/vm/drop_caches
$ LD_BIND_NOW=1 LD_DEBUG=statistics MOZ_NO_REMOTE=1 firefox -ProfileManager
...
12716:
12716: runtime linker statistics:
12716: total startup time in dynamic loader: 200390724 clock cycles
12716: time needed for relocation: 2701125 clock cycles (1.3%)
12716: number of relocations: 2095
12716: number of relocations from cache: 1000
12716: number of relative relocations: 1850
12716: time needed to load objects: 197343234 clock cycles (98.4%)
...

so, in this run, the relocation clock cycles are 5% higher with bindnow,
but the total load time is 5% faster. But when I retry it, the deltas in
time are huge between runs. (You can see the bindnow effect on "number of
relocations", which seems to roughly match the counts seen with
LD_DEBUG=bindings.)

If anyone really feels strongly about it, I'm happy to turn off bindnow
by default, but it doesn't seem to be a problem from what I can see in the
testing.

-Kees

--
Kees Cook @debian.org


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110911021603.GB31645@outflux.net">http://lists.debian.org/20110911021603.GB31645@outflux.net
 
Old 09-11-2011, 02:21 AM
Guillem Jover
 
Default Hardening patch

On Thu, 2011-09-08 at 08:59:50 +0200, Raphael Hertzog wrote:
> New patches attached.

> >From 8ea91d6285f490d583f85e1b1621a67ccb33e64a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>
> Date: Wed, 27 Jul 2011 22:10:49 +0200
> Subject: [PATCH 2/3] dpkg-buildflags: emit hardening build flags by default
>
> + # Decide what's enabled
> + my %use_feature = (
> + "pie" => 0,
> + "stackprotector" => 1,
> + "fortify" => 1,
> + "format" => 1,
> + "relro" => 1,
> + "bindnow" => 1
> + );

Any reason you seem to have ignored the concerns I rised about
defaulting to bindnow?

In any case I don't think enabling this w/o further data demonstrating
it's fine to do so is acceptable, as fixing any such regression would
imply needing to hunt down packages built with the new flags and trigger
binNMUs for them all. The default for it can always be changed later
on, I don't see the need to rush it?

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110911022118.GA2408@gaara.hadrons.org">http://lists.debian.org/20110911022118.GA2408@gaara.hadrons.org
 
Old 09-11-2011, 06:19 AM
Raphael Hertzog
 
Default Hardening patch

Hi,

On Sun, 11 Sep 2011, Guillem Jover wrote:
> > + "bindnow" => 1
>
> Any reason you seem to have ignored the concerns I rised about
> defaulting to bindnow?

Well, you mentioned potential performance problems and Kees said
that his tests did not conclude that it resulted in significant
performance loss. Kees has been doing the work, I trust him.

You told that you would expect the loss to be more significant
on slower architectures but you did not backup that claim with
anything. Of course 5% more of 200ms is not the same than 5%
of 2s but other than that, I do not see any technical reason
why they would be more affected than i386/amd64.

> In any case I don't think enabling this w/o further data demonstrating
> it's fine to do so is acceptable, as fixing any such regression would
> imply needing to hunt down packages built with the new flags and trigger
> binNMUs for them all. The default for it can always be changed later
> on, I don't see the need to rush it?

Feel free to change it if you think it's better that way. I'm not attached
to it.

But I'm not convinced that anyone will do the research that you require on
non-mainstream architectures and we will just end up with bindnow
disabled for the indefinite future.

OTOH I don't think that a 5% performance loss at startup time will ever be
used as a reason to bin-NMU all affected packages but only those that
are so big that they are suffering from it or a few that are performance
critical.

Your mileage may vary.

Please do the change yourself if you want it, I will soon go away for
the rest of the day.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110911061942.GB9020@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110911061942.GB9020@rivendell.home.ouaza.com
 

Thread Tools




All times are GMT. The time now is 08:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org