On Tue, Jul 19, 2011 at 09:31:58AM +0200, Carsten Strotmann wrote: > On 7/18/11 10:26 PM, Gábor Lénárt wrote: > >> PIC-related slowdown is about 5% (or less) on x86 on my test > >> including both multimedia and crypto operations. > > And if I compile it "by hand" anyway, it can be > > called nice to eliminate this, even if it only gives 5% or even just > > 0.1% :) > > There is a 'performance' vs. 'security' trade-off here. PIC/PIE > compiling has been introduced for a reason, it usually increases the > resilience against the damage done by certain attacks on security > vulnerabilities in code:
I don't think it was the original idea behind this (but surely it can have benefits you mention too): shared libraries are introduced because of the need to shared (that's why the same: .so=shared object) common code which is used by multiple running processes, thus it's a good idea not to have linked the same functionality statically into each of them, etc. Also it can be useful to upgrade only the library but not the code itself which uses it, which indeed can be useful. From this point of view, I only use ldns with unbound, so it's not a major win for me. Also, if I would upgrade only ldns or unbound I still recompile them together, getting the freshest copies of each (now, because ldns is not shipped with unbound anymore), so I can't see problem here. > > PIE stands for 'Position Independent Executable' and describes a > > function where the operating system can load certain parts of the > > application at random positions inside the computers address space. > > In some attacks the attacker needs to know beforehand on which memory > > location a datastructure will be loaded (e.g. to jump into code that > > has been written using a buffer overflow). By having the operating > > system load the program code into different locations every time, the > > attacker cannot predict the memory location, which makes it harder to > > write a successful exploit. > > http://blog.atariwiki.strotmann.de/roller/dnsworkshop/date/20110703 > > If you run Unbound in an untrusted network (e.g. Internet), having > Unbound PIC/PIE compiled might be a good idea from a security point of view. Surely, security can be increased even to a level where it goes unusable :) Ok it was more like a joke and a general wishdom, what I meant that of course there is always a balance between security and usability and sometimes it's hard to find the "good way" between the two borders. However I think all of you replied me here missed one point: as I've written even in my first (or second?) mail, I don't think that unbound team "has no right" to make the decision not to ship ldns "built-in" anymore, of course! I only wrote because the explanation of the change was strange for me: that distro maintrainers also asked for this move. However unbound configure mechanism can be made in a way (if it was not before? I can't remember) to only build and link against the built-in ldns _only_ if it was requested. So then there is no problem, as it can't happen "by mistake": using built-in ldns must be requested and never happen "automatically". That was the only intent of my mail originally. Surely, we can discuss and mention more advantages and/or disadvantages of this scheme but it's already another question then. The fact that I'd like to link against ldns statically is another topic, and I don't want make others to beleive it's better or the opposite: it's just my taste, nothing more or less. However what I mentioned was only the _real_ problem that --enable-static-exe should work, but it does not work for me, which is a real issue (I think) regardless of arguing about the advantages and disadvantages of my way to build unbound :) - Gábor _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
