On 16 September 2015 at 15:28, Borislav Petkov <bp@xxxxxxx> wrote: > On Wed, Sep 16, 2015 at 01:25:06PM +0200, Ard Biesheuvel wrote: >> ... so even if we wanted to, it would be intractible to find each >> cross-section relative reference and do the fixup. > > Hmm, maybe we should go and patch EFI code segments and fixup all > relative references after mapping. I mean, if you want something done > right, you better do it yourself. :-\ > That is a can of worms I'd rather keep closed, if you don't mind ... >> No, it seems nobody thought of this when designing the feature. > > Not surprised at all, to be honest. > >> Several solutions and/or work arounds are currently under discussion. > > And requiring for code segments not to refer to each other with relative > offsets and holding that down in the spec post-factum is not possible > anymore...? > > [ I can already imagine what the answer to that question would be though... ] > Fixing the spec is easy. Modifying all the toolchains out there to add an option that inhibits cross-section relative references is the problem. Note that, at the object level, it is not necessarily obvious to the compiler whether a symbol reference will end up referring to another section than its own. So this basically means 'no relative references at all', and most compilers don't have that option yet. [Note that GCC's large code model, which makes no assumption about the proximity of external symbols, may still emit PC relative literals (e.g., '.quad sym - .') on ARM. Not sure about X64) But in general, since we are already violating the PE/COFF spec by relocating each runtime image once, then invoke its entry point, then fire an event which it should catch to manually update its pointers, and then relocate it again into the OS VA space. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html