[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.2103311824590.2351@monopod.intra.ispras.ru>
Date: Wed, 31 Mar 2021 18:27:58 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
