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.