[FFmpeg-devel] [PATCH]configure: Enable pie for toolchain=hardened.

[Andreas Cadhalpun]

On 12.10.2016 23:44, Carl Eugen Hoyos wrote:
> 2016-10-12 19:04 GMT+02:00 Andreas Cadhalpun <andreas.cadhalpun at googlemail.com>:
>> On 04.10.2016 12:24, Carl Eugen Hoyos wrote:
>>> Sorry if I miss something but with this patch, the hardening_check
>>> script succeeds here both for x86_32 and x86_64 (static and shared).
>>
>> This script uses a very simplistic approach for testing position
>> independent executables.
>> I think it just does the equivalent of 'readelf -h $PROGRAM | grep Type'.
>> If the Type is EXEC, it's a normal executable, and if it is DYN, it
>> assumes it's compiled as PIE.
> 
>> However, that doesn't guarantee that the executable is actually position
>> independent, i.e. does not contain text relocations.
> 
> My understanding of PIE is (very) limited but I suspect text relocations
> and PIE do not exclude each other.

As I understand it the literal meaning of position independent code is
code without text relocations, because those are what makes the code
position dependent. So in this literal sense PIE and text relocations
exclude each other.
(The -fPIC/-fPIE flags tell the compiler to produce code without text
relocations.)

The additional complication for executables is that ASLR doesn't work for
normal executables, because they are always mapped to the same point in
address space. The basic idea of PIE is to build the executables actually
as shared libraries, so that they can benefit from ASLR just as normal
shared libraries.
(The '-pie' flag tells the linker to produce such an executable.)

However, such a '-pie' executable is not necessarily position independent
in the literal sense, i.e. might contain text relocations.
In that sense PIE and text relocations don't exclude each other.

If you want both NX and ASLR security features for an executable it has
to be built with '-pie' and must not contain text relocations.

>>> --- a/configure
>>> +++ b/configure
>>> @@ -3577,6 +3577,8 @@ case "$toolchain" in
>>>          add_cppflags -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
>>>          add_cflags   -fno-strict-overflow -fstack-protector-all
>>>          add_ldflags  -Wl,-z,relro -Wl,-z,now
>>> +        add_cflags   -fPIE
>>
>> I think this should be -fPIC, at least when building shared libraries.
> 
> Afaiu, shared libraries and PIE do exclude each other, pic is already
> supported in FFmpeg (--enable-pic) but this patch is only meant for
> PIE.
> 
>> That's how I understand the gcc manual [1]:
>> -fpie
>> -fPIE
>>     These options are similar to -fpic and -fPIC, but generated position
>>     independent code can be only linked into executables.
> 
> So shared libraries and PIE exclude each other but PIE is for
> static linking what pic is for dynamic linking.
> Good to know!

I think you misunderstood this. The problem with -fPIE is that it allows the
compiler to make optimizations only suitable if the resulting object ends
up in an executable. However, it is entirely possible to build the objects
with -fPIC and produce an executable with '-pie'. These same objects can
also be used to build normal shared libraries, while objects compiled
with '-fPIE' shouldn't be used for that. And '-pie' is also useful for
dynamic linking.

So using -fPIC in CFLAGS and '-fPIC -pie' in LDEXEFLAGS should always work.

>>> +        add_ldexeflags -fPIE -pie
>>>      ;;
>>>      ?*)
>>>          die "Unknown toolchain $toolchain"
>>> -- 1.7.10.4
>>
>> In general, enabling PIE for toolchain=hardened is a good idea.
> 
>> But According to [2] PIE doesn't work on hppa and m68k, so it
>> shouldn't get enabled for these architectures.
> 
> I was convinced that my ancient Linux system wouldn't know
> about ASLR but to my surprise, I was able to reproduce that
> my patch actually works (56bit entropy iiuc).
> My hppa test-system is currently down (and all reports about
> pie not working on hppa seem to be from 2008),

The information from the wiki might be outdated...

> I will try to test,
> in any case, I will commit the patch soon.
> 
> I will not be able to test on m68k.

I can't test hppa or m68k directly either.

Best regards,
Andreas