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

[Sean Silva via llvm-commits]

On Mon, Feb 1, 2016 at 12:27 PM, Rui Ueyama <ruiu at google.com> wrote:

> Even if a file is technically sane, you can craft a malicious one; for
> example, you can probably crash the linker by OOM by setting a very large
> number as an alignment requirement for each section so that the size of
> output becomes huge. It is easily doable using assembly. So my answer
> is "any clang or gcc produced .o not including inline asm". (It does not
> mean that we do not try to recover from errors caused by bad assembly code,
> but we don't/can't guarantee 100% recovery.)
>

You can probably find some way to set the alignment using an attribute or
whatever even from clang (and without inlineasm).

I don't think there is a platonically-ideal answer for this. It's more
about goals:
- as a command line tool, we don't want legitimate users to see us crashing
during normal use (if a user is intentionally trying to kill LLD, it is not
as embarrassing though, so we don't need to worry much about that case).
- we want to be useful (someday) as a library that can be safely used
in-process, so we need to provide certain guarantees (but these are not
hugely constraining, because we can assume that the calling code is
programmatically generating the file in good faith).

-- Sean Silva


>
> On Mon, Feb 1, 2016 at 12:11 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>> On 1 February 2016 at 15:06, Rui Ueyama <ruiu at google.com> wrote:
>> > 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?)
>>
>> It is definitely not a use case *I* have an interest in. I just want
>> to be an agreement on what use case we want to support at the moment.
>> Is it "any .o file", "any llvm-mc or gas produced .o", "any clang or
>> gcc produced .o not including inline asm"?
>>
>> Cheers,
>> Rafael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160201/6ab04d94/attachment.html>