From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 5ed52564 for ; Fri, 31 Jan 2020 16:40:23 +0000 (UTC) Received: (qmail 17496 invoked by uid 550); 31 Jan 2020 16:40:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17475 invoked from network); 31 Jan 2020 16:40:21 -0000 Date: Fri, 31 Jan 2020 11:40:09 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200131164009.GI1663@brightrain.aerifal.cx> References: <20200129191946.GI2020@voyager> <20200130170249.GK2020@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment On Fri, Jan 31, 2020 at 06:16:19PM +0300, Андрей Аладьев wrote: > Hello Markus, I want to ask a question about this one: > > > The issue is more complicated, because the app can have an unbounded > number of PT_LOAD segments with the PF_W flag absent. So checking the > relocations would require the dynlinker to first iterate over all PHDRs to > check for the unlikely case that textrels are present. Only because they > might be. > > I made a light code overview and found that there is already a mapping for > segments: "loadmap": > > dso->loadmap->segs[i].p_vaddr = ph->p_vaddr; > dso->loadmap->segs[i].p_memsz = ph->p_memsz; This is only for FDPIC, which is not used on any platforms you care about unless you already know what it is. :-) > We can add here the following line: > dso->loadmap->segs[i].readonly = ph->p_flags & PF_W; > > Than add "readonly" into "fdpic_loadseg": > struct fdpic_loadseg { > uintptr_t addr, p_vaddr, p_memsz; > bool readonly; > }; No you can't, because this structure is ABI between the loader (kernel or otherwise) and the program. It's not an internal structure of the dynamic linker. Moreover, adding such a thing is not desirable because it adds a linear-search of an array of load segments to each relocation, increasing load time of every correct program for the sake of diagnosing incorrect ones in a friendly manner. This is not a reasonable tradeoff and it's why I proposed the "hull" approach (that's O(1) and safe against bogus relocations clobbering memory outside the range of the library being relocated, but could still fault with a mix of LOAD maps). The FDPIC approach is only done because it's essential for being able to share program text on a system without MMU, not because it's "nice". Rich