Re: [PATCH] elf: Stop with zero entry point value [BZ #28453]

[Florian Weimer <fweimer@redhat.com>]

* Florian Weimer:

> * H. J. Lu via Libc-alpha:
>
>> Stop with zero entry point value unless we are tracing shared objects
>> since a zero entry point value in the ELF header indicates there is no
>> associated entry point.  Now we get
>>
>> $ ./elf/ld.so /lib64/libstdc++.so.6.0.29
>> ./elf/ld.so: cannot execute '/lib64/libstdc++.so.6.0.29' without entry point
>> $
>>
>> instead of
>>
>> $ /lib64/ld-linux-x86-64.so.2 /lib64/libstdc++.so.6.0.29
>> Segmentation fault (core dumped)
>> $
>>
>> This fixes [BZ #28453].
>
> Hah.  We recently had a downstream request to fix this.
>
>> +$(objpfx)tst-rtld-run-dso.out: tst-rtld-run-dso.sh $(objpfx)ld.so \
>> +			    $(objpfx)testobj1.so
>> +	$(SHELL) tst-rtld-run-dso.sh $(objpfx)ld.so $(objpfx)testobj1.so \
>> +	    '$(test-wrapper-env)' '$(run_program_env)' > $@
>> +	$(evaluate-test)
>> +

And I forgot to fill in the blanks:

Nick changed binutils very recently to default a zero entry point if
_start is not defined.  Before ld just used the lowest text address as
the entry point (apparently a leftover from the a.out days).

This means we need to link testobj1 with -Wl,--entry=0 (or use a new
test object).

>> diff --git a/elf/rtld.c b/elf/rtld.c
>> index 6ce1e07dc0..77bcdf8e29 100644
>> --- a/elf/rtld.c
>> +++ b/elf/rtld.c
>> @@ -1424,6 +1424,14 @@ dl_main (const ElfW(Phdr) *phdr,
>>  	 implementations which has no real free() function it does not
>>  	 makes sense to free the old string first.  */
>>        main_map->l_name = (char *) "";
>> +
>> +      /* Stop if there is no associated entry point and we are not
>> +         tracing shared objects.  */
>> +      if (main_map->l_entry == main_map->l_addr
>> +	  && state.mode != rtld_mode_trace)
>> +	_dl_fatal_printf("%s: cannot execute '%s' without entry point\n",
>> +			 ld_so_name, _dl_argv[_dl_argc -1]);
>
> Missing space before 1.
>
> Should we say “cannot execute shared object” or “cannot exe[cute a]
> shared library directly”?  execve should fail with ELIBEXEC, and the
> error messages should match.
>
> Should this check come later, after we have run ELF constructors, to
> maximize backwards compatibility?  ELF constructors might never return.
>
> Thanks,
> Florian