This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] elf: Refuse to dlopen PIE objects [BZ #24323]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <codonell at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 29 Apr 2019 23:35:20 +0200
- Subject: Re: [PATCH] elf: Refuse to dlopen PIE objects [BZ #24323]
- References: <20190312130235.8E82C89CE49C@oldenburg2.str.redhat.com> <d73b0cf4-c226-2abf-3f1c-59693cd11fd9@redhat.com>
* Carlos O'Donell:
>> ifeq (yes,$(build-shared))
>> # NB: Please keep cet-built-dso in sysdeps/x86/Makefile in sync with
>> diff --git a/elf/dl-load.c b/elf/dl-load.c
>> index 2bbef81b6e..9b0c1406c9 100644
>> --- a/elf/dl-load.c
>> +++ b/elf/dl-load.c
>> @@ -1158,6 +1158,10 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd,
>> goto call_lose;
>> }
>> + /* dlopen of an executable is not valid because it is not
>> possible
>> + to perform proper relocations and run the ELF constructors.
>> + For PIE, the check needs the dynamic section, so there is
>> + another check below. */
>
> Suggest you mention exactly which relocations are the problem.
> I assume it's COPY relocs into the main executable which can't be
> done twice, because both execs will want to reference their own
> copy. Likewise the problem with ELF constructors should be expanded
> with more details.
I assume that static TLS is also negatively impacted. TLS variables
from the dlopen'ed PIE binary and the real main program will probably
overlap.
Thanks,
Florian