Date: Wed, 31 Mar 2021 11:02:11 -0400 From: Rich Felker <dalias@...c.org> To: Alexander Monakov <amonakov@...ras.ru> Cc: musl@...ts.openwall.com Subject: Re: 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
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.