This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: LLVM collaboration?


On Wed, Feb 12, 2014 at 5:22 PM, Jan Hubicka <hubicka@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
>> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]