From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28495 invoked from network); 31 Mar 2021 14:51:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2021 14:51:41 -0000 Received: (qmail 3979 invoked by uid 550); 31 Mar 2021 14:51:38 -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 3955 invoked from network); 31 Mar 2021 14:51:37 -0000 Date: Wed, 31 Mar 2021 17:51:26 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com In-Reply-To: <20210331143330.GE25400@brightrain.aerifal.cx> Message-ID: References: <20210331143330.GE25400@brightrain.aerifal.cx> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] RELRO vs deferred binding On Wed, 31 Mar 2021, Rich Felker wrote: > Thanks for raising this. I think deferred binding needs to be updated > either to ignore RELRO if there are outstanding relocations (possibly > deferring it until they are all resolved) This seems undesirable as it leaves GOT unprotected for the rest of run time if unresolved relocations remain. > or to unprotect and > reprotect on every incremental link. (This could be optimized out and > preserve some further safety by scanning the outstanding relocation > table and skipping the unprotect/reprotect if none of them lie in the > RELRO range.) Even better might be to do relocation normally and lazily unprotect RELRO on first relocation that needs that, then reprotect once done with that DSO. (i.e. without doing an additional scan, like your parenthesized statement seems to suggest) Alexander