Date: Wed, 16 Sep 2015 01:36:04 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: dynamic linker bootstrap/rcrt changes On Fri, Sep 11, 2015 at 02:45:04AM -0400, Rich Felker wrote: > Working on static-PIE and FDPIC has shown the current approach (symbol > name lookup of "__dls2") to getting from stage 1 to stage 2 is not > what we should be doing. It requires -rdynamic for static PIE to work, > which is clunky and potentially bloated for large programs, and for > FDPIC the symbol lookup does not produce a callable function pointer > but rather an actual code address. > > What I'd like to do is punt on having _[dl]start_c make the call into > __dls2 and instead have it return, leaving the calling asm again > responsible for chaining into the next stage. This brings back a small > asm burden I'd tried to eliminate, but it reduces code size and > eliminates the above problems. > > One way we might could mitigate the asm burden is by having the crt > asm leave an extra N words below the original sp (argv-1) when making > the calls. This would give us space to pass state from stage 1 to > stage 2 (and possibly beyond) without the need for per-arch asm to > shuffle around argument registers and individual stack slots. This > would make it so each stage could take a single argument, orig_sp. I've devised what seems to be a good way to fix the current problems (-rdynamic requirement for static-PIE and lack of FDPIC support) without doing any of the above to complicate (or even change) the contract between crt_arch.h and the function it calls (aside from adding extra args for FDPIC). The basic idea is to perform the lookup of the stage-2 function via a small asm macro provided by the arch's reloc.h. Doing it in asm is necessary as a barrier to prevent the load from being hoisted before the self-relocation code and to avoid generating PIC code that could not safely run before there's a working GOT. On i386, it looks like this: diff --git a/arch/i386/reloc.h b/arch/i386/reloc.h index b52ef40..ea06e41 100644 --- a/arch/i386/reloc.h +++ b/arch/i386/reloc.h @@ -14,3 +14,7 @@ #define CRTJMP(pc,sp) __asm__ __volatile__( \ "mov %1,%%esp ; jmp *%0" : : "r"(pc), "r"(sp) : "memory" ) + +#define GETFUNCSYM(fp, sym, got) __asm__ ( \ + ".hidden " #sym " ; call 1f ; 1: addl $" #sym "-.,(%%esp) ; pop %0" \ + : "=r"(*fp) : : "memory" ) diff --git a/src/ldso/dlstart.c b/src/ldso/dlstart.c index 3aaa200..eb919ab 100644 --- a/src/ldso/dlstart.c +++ b/src/ldso/dlstart.c @@ -74,6 +74,7 @@ void _dlstart_c(size_t *sp, size_t *dynv) *rel_addr = (size_t)base + rel; } +#ifndef GETFUNCSYM const char *strings = (void *)(base + dyn[DT_STRTAB]); const Sym *syms = (void *)(base + dyn[DT_SYMTAB]); @@ -85,6 +86,11 @@ void _dlstart_c(size_t *sp, size_t *dynv) break; } ((stage2_func)(base + syms[i].st_value))(base, sp); +#else + stage2_func dls2; + GETFUNCSYM(&dls2, __dls2, base+dyn[DT_PLTGOT]); + dls2(base, sp); +#endif } #endif The got-pointer argument is provided to the macro in case it's needed on some archs; on many, DT_PLTGOT is not even set and thus not usable. This should only be needed on FDPIC, where it won't actually be base+... but rather an address that's properly adjusted for the segment. For example on SH-FDPIC it looks like: #define GETFUNCSYM(fp, sym, got) __asm__ ( \ "mov.l 1f,%0 ; add %1,%0 ; bra 2f ; nop ; .align 2 \n" \ "1: .long " #sym "@GOTOFFFUNCDESC \n2:" \ : "=&r"(*fp) : "r"(got) : "memory" ) The point of returning the function address instead of just making a call from asm is that we want the compiler to generate a tail-call, so that the (considerable on a NOMMU scale) stack space used by the self-relocation code gets freed before transferring control to the main program. So far I have this working on i386 and sheb-nofpu-fdpic (for the latter, with a highly-modified, fdpic-oriented dlstart.c) but it should not be hard to adapt to other archs. If it seems ready to commit, I can leave the above #ifdef in place during transition so that not all archs have to transition in a single commit. 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.