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 29901 invoked from network); 31 Mar 2021 15:02:28 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 31 Mar 2021 15:02:28 -0000
Received: (qmail 11987 invoked by uid 550); 31 Mar 2021 15:02:24 -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 11966 invoked from network); 31 Mar 2021 15:02:23 -0000
Date: Wed, 31 Mar 2021 11:02:11 -0400
From: Rich Felker <dalias@libc.org>
To: Alexander Monakov <amonakov@ispras.ru>
Cc: musl@lists.openwall.com
Message-ID: <20210331150211.GF25400@brightrain.aerifal.cx>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LNX.2.20.13.2103311745100.2351@monopod.intra.ispras.ru>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] RELRO vs deferred binding

On Wed, Mar 31, 2021 at 05:51:26PM +0300, Alexander Monakov wrote:
> 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.

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.

> > 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)

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?

Rich