[PATCH] D16599: ELF: Define another entry point.

[Rui Ueyama via llvm-commits]

On Mon, Feb 1, 2016 at 11:57 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 1 February 2016 at 14:46, Sean Silva <chisophugis at gmail.com> wrote:
> > I think one of the main use cases that has been requested is to be able
> to
> > programmatically call the linker with "known good" object files (i.e.
> > produced by the compiler). That simplifies things a lot. Rui's recent
> > patches that are thread_local'izing existing globals seems like a
> > satisfactory approach. Or am I missing something?
>
> Yes, known good files are a lot easier to handle. We just have to be
> clear what "known good" is.
>
> > The R_X86_64_REX_GOTPCRELX situation can probably be likened to someone
> > giving clang a piece of source code with an inline asm that has:
> >
> > .text
> > .byte <some garbage>
> >
> > in it. We don't guarantee that the output "makes sense" because there's
> > really no way for us to know what "makes sense" in a precise way (i.e., a
> > way that we can program).
>
> Would we still be required to check the offsets so we don't crash? An
> assembly file can contain
>
> .reloc 0, R_X86_64_REX_GOTPCRELX, foo
> .long 4
>
> which would put that relocation in an invalid location. In general, is
> an arbitrary assembly file to be considered "known good"? Is that true
> even for things like
>
> .section .eh_frame, ....
> garbage
>
> that the linker has to parse?
>

I think the answer is case-by-case, but I don't think we have to guarantee
to recover from errors caused by carefully-crafted malicious object files.
(Is there anyone who disagrees with that?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160201/dca16f00/attachment.html>