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 482 invoked from network); 31 Mar 2021 15:28:15 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2021 15:28:15 -0000
Received: (qmail 30422 invoked by uid 550); 31 Mar 2021 15:28:10 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 30404 invoked from network); 31 Mar 2021 15:28:10 -0000
Date: Wed, 31 Mar 2021 18:27:58 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: musl@lists.openwall.com
In-Reply-To: <20210331150211.GF25400@brightrain.aerifal.cx>
Message-ID: <alpine.LNX.2.20.13.2103311824590.2351@monopod.intra.ispras.ru>
References: <alpine.LNX.2.20.13.2103311716370.2351@monopod.intra.ispras.ru> <20210331143330.GE25400@brightrain.aerifal.cx> <alpine.LNX.2.20.13.2103311745100.2351@monopod.intra.ispras.ru> <20210331150211.GF25400@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:

> > This seems undesirable as it leaves GOT unprotected for the rest of
> > run time if unresolved relocations remain.
> 
> Yes, but in practice this is only for broken xorg modules and the
> unresolved relocations are resolved by the time any attack-surface
> code runs, no? Still I agree it's better to avoid this.

Yeah, you never know what other software may depend on this in the future.

> That puts the additional branch/logic inside the hot path used by all
> relocation processing rather than a path that's relegated to just
> outstanding relocations on libraries that didn't declare their
> dependencies properly.
> 
> My version looks something like, inside the for loop in
> redo_lazy_relocs:
> 
> 	need_unprotect = 0;
> 	for (i=0; i<size; i+=3);
> 		if ((uintptr_t)laddr(p, p->lazy[i])-relro_start < relro_end)
> 			need_unprotect = 1;
> 	if (need_unprotect) mprotect(...);
> 	do_relocs(...);
> 	if (need_unprotect) mprotect(...);
> 
> Does that look reasonable?

Thanks, now I see what you had in mind. Sure, this looks nice.

Alexander