On Sat, Oct 22, 2011 at 5:46 PM, Matthias Klose wrote:
>> Two hardening features are not enabled by default: PIE and bindnow.
>> If your package supports PIE, you might want to consider enabling it.
>
> You should not blindly enable PIE, even if the package seems to support it.
> PIE
> can ha
> Two hardening features are not enabled by default: PIE and bindnow.
> If your package supports PIE, you might want to consider enabling it.
You should not blindly enable PIE, even if the package seems to support it. PIE
can have runtime performance impacts up to 25% for some binaries on som
On Tue, Oct 4, 2011 at 11:33 AM, Roger Leigh wrote:
> On Tue, Oct 04, 2011 at 09:29:27AM +0200, Bastien ROUCARIES wrote:
>> On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote:
>> > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
>> >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weim
On Tue, Oct 04, 2011 at 09:29:27AM +0200, Bastien ROUCARIES wrote:
> On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote:
> > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
> >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
> >> > Not necessarily. -fPIC and -fPIE force
On Mon, Oct 3, 2011 at 7:31 PM, Bernhard R. Link wrote:
> * Bastien ROUCARIES [111003 17:27]:
>> > Not necessarily. -fPIC and -fPIE force calls to global functions
>> > defined in the same translation unit to go through the PLT. They
>> > aren't translated to direct IP-relative calls. For -fPI
On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote:
> On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
>> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
>> > Not necessarily. -fPIC and -fPIE force calls to global functions
>> > defined in the same translation unit to go t
On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
> > Not necessarily. -fPIC and -fPIE force calls to global functions
> > defined in the same translation unit to go through the PLT. They
> > aren't translated to direct IP-rel
* Alastair McKinstry [111003 12:48]:
> I would defend static libs for scientific apps. Static libs show a
> significant performance
> benefit (2-40%, median around 5-10% but sometimes far more with C++
> apps)
Are those numbers only the position independent code (I guess mostly
the register avail
* Bastien ROUCARIES [111003 17:27]:
> > Not necessarily. -fPIC and -fPIE force calls to global functions
> > defined in the same translation unit to go through the PLT. They
> > aren't translated to direct IP-relative calls. For -fPIC, this is
> > required by the ELF specification (no kidding,
On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
> * Adam Borowski:
>
>>> I would defend static libs for scientific apps. Static libs show a
>>> significant performance benefit (2-40%, median around 5-10% but sometimes
>>> far more with C++ apps) and so are standard in HPC still;
>>
>> If you
* Bastien ROUCARIES:
> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
>> * Adam Borowski:
>>
I would defend static libs for scientific apps. Static libs show a
significant performance benefit (2-40%, median around 5-10% but sometimes
far more with C++ apps) and so are standa
* Adam Borowski:
>> I would defend static libs for scientific apps. Static libs show a
>> significant performance benefit (2-40%, median around 5-10% but sometimes
>> far more with C++ apps) and so are standard in HPC still;
>
> If you see that big a difference, you do a lot of cross-file calls in
* Henrique de Moraes Holschuh:
> On Sun, 02 Oct 2011, Florian Weimer wrote:
>> Couldn't we get rid of static libraries altogether, replacing static
>> linking with ahead-of-time dynamic linking?
>
> Well, the normal usecase for static libraries and static linking is to
> produce self-contained obj
On Mon, Oct 03, 2011 at 11:20:11AM +0100, Alastair McKinstry wrote:
> On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote:
> >On Sun, 02 Oct 2011, Florian Weimer wrote:
> >>Couldn't we get rid of static libraries altogether, replacing static
> >>linking with ahead-of-time dynamic linking?
> >
>
On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote:
On Sun, 02 Oct 2011, Florian Weimer wrote:
Couldn't we get rid of static libraries altogether, replacing static
linking with ahead-of-time dynamic linking?
[1] but I don't feel strong enough about it to get in the way if we do
decide to d
On Sun, 02 Oct 2011, Florian Weimer wrote:
> Couldn't we get rid of static libraries altogether, replacing static
> linking with ahead-of-time dynamic linking?
Well, the normal usecase for static libraries and static linking is to
produce self-contained objects. If you can link a bunch of dynamic
* Florian Weimer (f...@deneb.enyo.de) [111002 21:59]:
> Couldn't we get rid of static libraries altogether, replacing static
> linking with ahead-of-time dynamic linking?
Could you explain what this means for people not so deep into that?
(E.g. how is the linking done? When? What does that mean fo
* Kees Cook:
> When we decide to build an entire architecture as PIE, then we'll also need
> to build those static libs with -fPIE too.
Couldn't we get rid of static libraries altogether, replacing static
linking with ahead-of-time dynamic linking?
There's still a theoretical difference between
On Thu, Sep 29, 2011 at 06:41:29AM +0900, Charles Plessy wrote:
> Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit :
> > On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> > > Two hardening features are not enabled by default: PIE and bindnow.
> > > If your package su
On Wed, Sep 28, 2011 at 11:38:06PM +0200, Mike Hommey wrote:
> On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> > On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > > register-starved architecture
On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > register-starved architectures (i386) in most cases, for for certain work
> > loads (e.g. python)
Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit :
> On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> > Two hardening features are not enabled by default: PIE and bindnow.
> > If your package supports PIE, you might want to consider enabling it.
> > If the binarie
On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > register-starved architectures (i386) in most cases, for for certain work
> > loads (e.g. python)
On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> Just to be explicit, PIE tends to have small (<1%) performance hits on
> register-starved architectures (i386) in most cases, for for certain work
> loads (e.g. python) the hit is large (~15%). On architectures with plenty
> of registers
* Ian Jackson [110927 20:21]:
> Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> > things to be in a users environment, so a package's rules file should
> > in
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> Two hardening features are not enabled by default: PIE and bindnow.
> If your package supports PIE, you might want to consider enabling it.
> If the binaries are long running processes like daemons, and as such
> the startup
Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> things to be in a users environment, so a package's rules file should
> in my eyes not depend on them not being set or ha
* Bernd Zeimetz [110927 15:36]:
> > I'm one of the submitters of one of the bugs which requested this
> > change. This is a reversion of dpkg to a previous behaviour, and it
> > /un/breaks packages. Or at least I think it unbreaks much more than
> > it breaks.
>
> ACtually I think that is true -
On 09/24/2011 05:48 PM, Ian Jackson wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
>> Raphael Hertzog wrote:
>>> * dpkg-buildpackage no longer exports
>>> CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>>
>> | You don
I wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > My concern is that we now have a whole history of ill-considered changes
> > to the build flags. To the point that it's possible to argue that every
> > build flag change save one*
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Ian Jackson wrote:
> > It was always completely wrong of dpkg-buildpackage to set these
> > variables. Source packages are entitled to assume that strange
> > environment variables which cause th
On Monday, September 26, 2011 08:21:19 PM Raphael Hertzog wrote:
> On Mon, 26 Sep 2011, Scott Kitterman wrote:
> > I can see where this might be useful for final work before an upload,
> > what is one expected to do when one is doing successive builds where
> > things change every time while workin
On Mon, 26 Sep 2011, Scott Kitterman wrote:
> I can see where this might be useful for final work before an upload, what is
> one expected to do when one is doing successive builds where things change
> every time while working on a package? dpkg-buildpackage -b, "Oh, fail",
> "dpkg-source --co
On Friday, September 23, 2011 08:17:54 AM Raphael Hertzog wrote:
> * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
> if it detects upstream changes which are not managed by a quilt patch.
>
> You are expected to call “dpkg-source --commit” if you want to
> record thos
On Mon, Sep 26, 2011 at 12:26 AM, Michael Gilbert wrote:
> I should have been more explicit. I was referring to dpkg-buildflags
> default outputs above.
I see, agreed then.
> I'm ok with the fact that each individual package will need to
> be changed to support this (vice forcing it into gcc).
Paul Wise wrote:
> On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote:
>
> > I think it would be better to enable all security-enhancing flags by
> > default (at least all of the included ones so far, which are fairly
> > well-tested). Yes, these two do have a larger potential to reduce
> > p
On Sat, 24 Sep 2011, Charles Plessy wrote:
> If in a large number of cases where one would like to turn off the patch
> system
> of the 3.0 (quilt) format, the source package is stored in a Git repository,
> then one way to move forward would be to make the format 3.0 (git) available
> in Debian.
On Sat, Sep 24, 2011 at 2:30 PM, Charles Plessy wrote:
> If in a large number of cases where one would like to turn off the patch
> system
> of the 3.0 (quilt) format, the source package is stored in a Git repository,
> then one way to move forward would be to make the format 3.0 (git) available
Ian Jackson wrote:
> I'm one of the submitters of one of the bugs which requested this
> change. This is a reversion of dpkg to a previous behaviour, and it
> /un/breaks packages. Or at least I think it unbreaks much more than
> it breaks.
>
> It was always completely wrong of dpkg-buildpackage
On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote:
> I think it would be better to enable all security-enhancing flags by
> default (at least all of the included ones so far, which are fairly
> well-tested). Yes, these two do have a larger potential to reduce
> performance, but its also suffi
berta...@ptitcanardnoir.org wrote:
> On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote:
> > On Sep 23, Raphael Hertzog wrote:
> >
> > > Two hardening features are not enabled by default: PIE and bindnow.
> > Why?
>
> I guess because they have more impact on performance than the oth
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Raphael Hertzog wrote:
> > * dpkg-buildpackage no longer exports
> > CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>
> | You don't know how many packages are broken or no longer
> | policy compl
Hello everybody,
If in a large number of cases where one would like to turn off the patch system
of the 3.0 (quilt) format, the source package is stored in a Git repository,
then one way to move forward would be to make the format 3.0 (git) available
in Debian. What are the blocking points ?
Che
On Fri, 23 Sep 2011 08:17:54 +0200, Raphael Hertzog wrote:
> * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
> if it detects upstream changes which are not managed by a quilt patch.
> * When dpkg-source automatically applies patches at the start of the
> build process,
Raphael Hertzog wrote:
> * dpkg-buildpackage no longer exports CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
| You don't know how many packages are broken or no longer
| policy compliant because they were relying on those environment
| variables
Who said that? Oh, yeah it was you.
How are we supposed
On Fri, 23 Sep 2011, Adam Borowski wrote:
> Old-style: rm -rf .pc debian/patches
> New-style: echo "single-debian-patch" >debian/source/options
--single-debian-patch is no longer "new" at this point. The fact that you
were not using it and relying on dpkg-source to generate a different patch
at ea
On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote:
> On Sep 23, Raphael Hertzog wrote:
>
> > Two hardening features are not enabled by default: PIE and bindnow.
> Why?
I guess because they have more impact on performance than the others.
> > If your package supports PIE, you migh
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> we just released dpkg 1.16.1 to unstable. It comes with several disruptive
> changes that you need to be aware of. Please read carefully.
> * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
> if it detects u
On Sep 23, Raphael Hertzog wrote:
> Two hardening features are not enabled by default: PIE and bindnow.
Why?
> If your package supports PIE, you might want to consider enabling it.
> If the binaries are long running processes like daemons, and as such
> the startup performance penalty of
49 matches
Mail list logo
