Re: Hardening patch
On Tue, 2011-09-13 at 08:51:17 +0200, Raphael Hertzog wrote:
> On Tue, 13 Sep 2011, Guillem Jover wrote:
> > I installed iceweasel on an ARM system (Thecus N2100), w/o X forwarding,
> > and no user profile, so it just stops when it's not able to find the
> > DISPLAY, but that should be good enough to get timings close to just the
> > startup relocation times, which is what the ld.so stats show on amd64
> > for example. Caches flushed on each iteration, which were pretty
> > consistent, I've included two different ones for each:
>
> I did the same on my eSATA SheevaPlug (armel too) and I don't get the same
> results than you.
[SheevaPlug tests]
> > As it can bee seen the difference is pretty significant.
>
> As it can be seen, the difference is not something that affects
> all armel machines in the same way.
>
> I did 10 run of each, dropped the biggest value and did the mean
> value on the rest:
> - bind lazy: 1.842s
> - bind now: 1.910s
>
> Difference: +3,6 %
Well an eSATA SheevaPlug is a pretty fast ARM machine! In any case it
was not my intention to imply all ARM machines would be affected
equally. I said the impact would be more noticable on slow architectures,
which ARM tends to be. In this case I/O is most probably the culprit,
something I hinted at on my first mail on this sub-thread. And this
will affect any system with slow I/O.
> > > Feel free to change it if you think it's better that way. I'm not attached
> > > to it.
> >
> > I'm changing it now on my local tree, will be included in my next
> > push.
I took the commit out from my push because this was still under
discussion, that does not mean I've changed my mind though and I
still do not really feel comfortable uploading a dpkg defaulting
to bind now.
> Given my test, I'm not convinced it's the right course of action.
>
> I did the same test on my i386 setup and I got this:
> - bind lazy: 0.320s
> - bind now: 0.330s
>
> Difference: +3,1 %
>
> At the very least, we could keep it enabled for i386/amd64, no ?
I've written some of this in some previous mail, but I'll repeat. This
can have real impact on performance, it potentially affects the whole
archive (once it all switches to using dpkg-buildflags), and even on
overally fast archiectures it might still affect a range of its slow
systems, once bind now is set on an object (via DF_1_NOW, DF_BIND_NOW
or DT_BIND_NOW) it cannot be disabled by neither of dlopen(RTLD_LAZY)
nor environment variables, it's trading an optimization with a security
measure.
So given its obvious drawbacks (something the other options do not
seem to present), that we can always change it in the future, I don't
think the current default should be changed. In this kind of case our
stance should really be “if in doubt, do not change”. But if this was
to get changed, this is something the project at large should get
consensus on, not just the dpkg team.
Of course specific maintainers are free to choose compilation options
for their own packages, because that does (generally) have a global
impact, and they can assess what side of the trade off is more
important.
regards,
guillem
Reply to: