[RFC PATCH v2] ld: Optionally nullify default PIE in all linker tests

[Jens Remus]

On 29.03.2025 02:32, Hans-Peter Nilsson wrote:
> On Fri, 28 Mar 2025, Jens Remus wrote:

>> Some distributions configure GCC with --enable-default-pie [1]. LLVM
>> defaults Clang to CLANG_DEFAULT_PIE_ON_LINUX=ON [2].  This causes
>> compiles to default to -fPIE and links to default to -pie, unless other
>> options are explicitly given.  As a consequence several linker tests
>> are compiled and linked in unexpected ways and may even unexpectedly
>> fail or pass.
>>
>> Add the configuration variable "NULLIFY_DEFAULT_PIE" to the linker test
>> suite to optionally nullify default PIE, by prepending $NOPIE_CFLAGS to
>> the compile flags and $NOPIE_LDFLAGS to the link flags for all linker
>> tests.  These are then overridden by any deviating compiler flags
>> (e.g. -fPIC or -fPIE) and linker flags (e.g -pie or -shared) explicitly
>> specified by the tests.  Possible values of NULLIFY_DEFAULT_PIE are:
>>
>>    0: Do not nullify default PIE. (default)
>>    1: Unconditionally prefix $NOPIE_CLFAGS and $NOPIE_LDFLAGS.
>>    auto: Prefix $NOPIE_CLFAGS and $NOPIE_LDFLAGS if compiler configured
>>      to default to PIE.
>>
>> NULLIFY_DEFAULT_PIE can for instance be specified via RUNTESTFLAGS:
>>
>>    $ make check RUNTESTFLAGS="NULLIFY_DEFAULT_PIE=1"
>>
>> or in ~/.dejagnurc:
>>
>>    # Prefix $NOPIE_CLFAGS and $NOPIE_LDFLAGS if compiler defaults to PIE.
>>    set nullify_default_pie "auto"
> 
> I can't help but thinking this is overthinking or
> overengineering, sorry.
> 
> Why not keep it simple: for each test creating an executable and
> that lacks an option mentioning specifying -pie -no-pie or
> -static, add "-no-pie"?  No $NOPIE_*.  (And subsequently make
> sure new tests mention such an option.)  IIRC, that's the way
> this (systems-having-different-pie-defaults) had been handled in
> the past.

Maybe I am missing something.  Reviewing all users of default_ld_compile,
whether they lack -fno-PIE, and all users of default_ld_link, whether
they lack -no-pie appears to be a huge effort.

Also if not using $NOPIE_*, would it be guaranteed that all compilers
meanwhile do support -fno-PIE and -no-pie?

In general have doubts how the outcome of your suggested approach would
differ from my RFC v1, which unconditionally nullified default PIE and
therefore was rejected by Alan, so that all existing tests that do not
explicitly specify to be built PIE would not be run both in PDE and PIE
flavors depending on the compiler.  Unless one would add test duplicates
with PIE flavor, as you also suggested.

Furthermore I fear that new tests will creep in that are developed
without considering compilers configured with default PIE.  If such
tests fail with default PIE, then this is of value, as it causes a
review of this "unexpected" flavor to decide whether it is invalid or
whether it uncovered an issue.  If such tests erroneously pass, then it
may cause an issue to remain undetected.

> For extra credit, for those tests with the new specified option,
> add an extra test with the inverted option, but as a separate
> patch.

My approach would allow to run the linker tests in what I suppose to be
their intended flavor (PDE) and in their unintended one (PIE), with the
default being the current state.  Of course this can also be achieved by
using a custom compiler configured without default PIE.

Thanks and regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/