[MPlayer-dev-eng] [PATCH] compile as PIE by default

[Reimar Döffinger]

On 22 May 2012, at 03:27, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> On 5/21/12, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
>> Hello,
>> below patch would compile MPlayer as PIE on x86 by default.
>> On 32 bit, the cost would only be in a larger binary size and having to do
>> relocations at startup, but no real cost at runtime.
>> On 64 bit, there is almost no size or runtime overhead, mostly that
>> in some cases PIC-relative addressing has to be used.
>> I believe that none of the assembler code will be disabled by either.
>> I have not made any changes to other architectures since I can't
>> judge the impact.
>> A side effect of the 64 bit case is that MPlayer will refuse to link
>> against some static libraries (those not compiled with PIC and thus
>> violating
>> the ABI), one example (which only exists as static library) is LIVE555
>> as provided by Debian.
>> Another point is that backtraces without debug info will probably be
>> even less useful.
>> Any comments? My belief is that there is negligible if any disadvantage
>> for a sometimes significant win in security.
>> 
>> Index: configure
>> ===================================================================
>> --- configure    (revision 34955)
>> +++ configure    (working copy)
>> @@ -2643,6 +2643,22 @@
>> fi
>> 
>> 
>> +# try to create a relocatable binary by default
>> +echocheck "relocatable binary"
>> +if x86_32 && cflag_check -pie ; then
>> +  extra_ldflags="$extra_ldflags -pie"
>> +  relocatable=yes
>> +  res_comment="non-PIC"
>> +elif x86_64 && cflag_check -fpie -pie ; then
>> +  extra_ldflags="$extra_ldflags -fpie -pie"
>> +  extra_cflags="$extra_cflags -fpie"
>> +  relocatable=yes
>> +  res_comment="fast PIC"
>> +else
>> +  relocatable=no
>> +  res_comment="unavailable or untested architecture"
>> +fi
>> +echores $relocatable
>> 
>> if x86_32 ; then
>>   # Checking assembler (_as) compatibility...
> 
> Without researching the topic.
> Would the above check fail if --enable-static is used?

I'll have to test, though it really shouldn't, these are orthogonal things (even though I admit it is a bit confusing).

> I think there must be a way to disable this with configure option,
> e.g. --disable-pie

Agreed in principle, I was too lazy to do it for an RFC oatch.

> Have you tested it with the win32loader?

Was a long time ago, so I don't remember. However we have no win32loader for 64 bit, and for 32 bit it is a link only option, so compiling should work.
The only issue should be that loading some dlls might randomly fail if MPlayer by chance is placed at the location where the dll needs to be loaded. Disabling address randomization for MPlayer would fix it, even if it eliminates the advantage.