Expanding the list of "Hardened Packages"

Paolo Bonzini pbonzini at redhat.com
Thu Apr 4 07:39:18 UTC 2013


Il 04/04/2013 04:05, Josh Bressers ha scritto:
> 
> 
> 
> On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb <sgrubb at redhat.com
> <mailto:sgrubb at redhat.com>> wrote:
> 
>     On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
>     > On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb <sgrubb at redhat.com
>     <mailto:sgrubb at redhat.com>> wrote:
>     > > On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote:
>     > > > "_hardened_build" rpm spec macro can be used to harden a package.
>     > > >
>     > > > For an example, see
>     > > > http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec
>     > >
>     > > This flag is overly aggressive. We have a list of programs that
>     need PIE
>     > > enabled and doing more isn't necessarily constructive.
>     >
>     > Why exactly it "isn't necessarily constructive"?  If you have hard
>     data,
>     > please share :)
> 
>     Because PIE is only supposed to be on long running apps and setuid
>     apps. If
>     its on everything, it will slow the system down too much and then
>     you have the
>     knee jerk reaction to remove it from anything. We want it applied
>     when needed
>     and otherwise not.
> 
> 
> How much does it slow things down? I'm fairly certain you don't have any
> good data on this point. Dhiru is working out how to best figure out FWIW.
> 
> I'm willing to agree that PIE on x86 is going to be very slow due to
> register pressure.

Yes, but not on x86-64 which has %rip-relative addressing.  It is
probably a wash there.

Also, it is not really _that_ slow.  The same register pressure issue
exists with PIC.  It was that bad, we would have problems for all the
code we run from shared libraries.

Paolo

> However, we should consider revisiting what we want
> built as PIE. Is Firefox a long running process? It is on my system.
> Revisiting our current list and trying to understand our needs is never
> a bad thing to do. Existing architectures are different now than they
> were when that list was created, no harm comes from talking about it.
> 
> -- 
>     JB
> 
> 



More information about the devel mailing list