On Wed, Feb 12, 2014 at 5:22 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> On Wed, 12 Feb 2014, Richard Biener wrote: >> >> > What about instead of our current odd way of identifying LTO objects >> > simply add a special ELF note telling the linker the plugin to use? >> > >> > .note._linker_plugin '/...../libltoplugin.so' >> > >> > that way the linker should try 1) loading that plugin, 2) register the >> > specific object with that plugin. >> >> Unless this is only allowed for a whitelist of known-good plugins in >> known-good directories, it's a clear security hole for the linker to >> execute code in arbitrary files named by linker input. The linker should >> be safe to run on untrusted input files. > > Also I believe the flies should be independent of particular setup (that is > not > contain a path) and probably host OS (that is not having .so extension) at > least. > We need some versioning scheme for different versions of compilers. > Finally we need a solution for non-ELF LTO objects (like LLVM) > > But yes, having an compiler independent way of declaring that plugin is needed > and what plugin should be uses seems possible.
Yeah, naming the plugin (and searching it in a ld specific trusted configurable path only) would work as well, of course. That also means that we should try to make the GCC side lto-plugin work for older GCC versions as well (we pick the lto-wrapper to call from the environment which would have to change if we'd try to support using multiple GCC versions at the same time). Richard. > Honza >> >> -- >> Joseph S. Myers >> jos...@codesourcery.com
