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

[Florian Weimer <fweimer@redhat.com>]

* 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)
> +



> 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