Expanding the list of "Hardened Packages"

[Jakub Jelinek]

On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote:
> On 04/04/13 at 09:26am, Steve Grubb wrote:
> > On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote:
> > > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > How much does it (PIE) 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. However, we should consider revisiting what we want
> > > built as PIE. Is Firefox a long running process?
> >
> > Firefox fits into the category of a parser of untrusted media. Therefore it
> > should hardened.
> 
> FWIW, Ubuntu has been shipping PIE enabled Firefox for years now.
> 
> https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/507744
> 
> I repeated the benchmarks (mentioned in the above bug report) for
> Firefox 20.0 running on Fedora 18 64-bit.

Firefox as benchmark doesn't look like a good idea (and I'm really surprised
that we don't compile it as PIE, I thought we've been doing that for years).
The special thing on firefox is that it is really tiny binary (< 64K of
.text) with almost no libraries linked directly (just -lc, -ldl, -lstdc++,
-lpthread and their dependencies (-lm, -lgcc_s)), so indeed the relocation
processing isn't very expensive (only ~ 130 relocations) before reaching
main and prelink can't make it significantly faster.  Firefox is designed
to dlopen all of its code from main and later on, something prelink doesn't
significantly improve (the only improvement could be if all/some of those
dlopened libraries were prelinked (or just prelink -R relocated) to picked
up addresses, then it could avoid relative relocation processing).
Even just starting firefox to show up a window shows around 8000 relocations
though, but except for the first ~ 130 everything is during dlopen.

If you want to benchmark something where it makes a difference, you want
to benchmark some program where the binary contains significant amount of
code, and which links against lots of shared libraries, or stuff like
configure scripts or similar usage scenarios where are thousands of small
short running programs spawned each second and where the relocation
processing consumes significant amount of time.

	Jakub