From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15701 invoked by alias); 10 Nov 2016 16:30:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 15417 invoked by uid 89); 10 Nov 2016 16:30:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1560 X-HELO: mx1.redhat.com Subject: _rtld_global_ro and static dlopen (was: Re: Pending fixes for all-ABIs builds) To: Andreas Schwab References: <35e9c513-c873-3d7e-38e4-6aa14e9ef245@redhat.com> <0a922f13-5130-51ca-fc73-6c003dbb20ce@redhat.com> <36be36df-87a8-22c3-ded4-38cfc69ab0df@redhat.com> <20161109215956.F31D52C39FE@topped-with-meat.com> Cc: Roland McGrath , Joseph Myers , libc-alpha@sourceware.org From: Florian Weimer Message-ID: Date: Thu, 10 Nov 2016 16:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00400.txt.bz2 On 11/10/2016 10:27 AM, Andreas Schwab wrote: > On Nov 10 2016, Florian Weimer wrote: > >> Could we put this information into rtld_global_ro, instead of having a >> separate variable? (Assuming that rtld_global_ro is indeed in read-only >> memory after relocation.) > > It cannot be read-only, it is set only after ld.so is initialized. I know that glibc has trouble with multiple definitions, but at least one copy of _rtld_global_ro *is* read-only after relocation: (gdb) print memset (&_rtld_global_ro, 1, 1) Program received signal SIGSEGV, Segmentation fault. __memset_sse2 () at ../sysdeps/x86_64/memset.S:110 110 movb %cl, (%rdi) It also contains a function pointer to _dl_lookup_symbol_x, so I think this data structure should work for locating ld.so functions. Is the problem that we determine too late that we are running in a nested configuration, and the inner ld.so has already been relocated? Maybe gdb is lying to me, but it seems that we run the inner libc.so with a _rtld_global_ro which has not been initialized beyond what is in the default initializer. It seems that dl_main never runs. But this means that most uses of GLRO inside libc.so.6 are broken. And indeed, GLRO (dl_auxv) does not work as intended, and results in a NULL pointer dereference in getauxval: https://sourceware.org/bugzilla/show_bug.cgi?id=20802 How can we fix this? Could we synthesize a link map which interposes the necessary definitions? Thanks, Florian