[Unbound-users] Unbound release 1.4.12

[Carsten Strotmann]

Hello Gábor,

On 7/19/11 10:27 AM, Gábor Lénárt wrote:
> 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.
> 

compiling 'position independent' (PIE/PIC) vs. 'fixed address code' is a
different topic than shared vs. static compiling. You can compile
PIE/PIC code with or without the use of shared libraries.

I was commenting on the performance slowdown of PIE/PIC code, that is a
security tradeoff. PIE/PIC change the way how executables are loaded and
mapped into memory.

There is also a security trade-off of using shared libraries, but that
is a different story.

-- Carsten