<div dir="ltr">And looks like r259597 was the last patch that had to be submitted to realize this policy. So, you can call the linker's entry point if you want and expect it to return in normal use cases. I hope that satisfies people's need who were looking for an alternative to the old linker's main function!</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 3:28 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thank you for the advice. I refined it a bit.</div><div><br></div><div><div>diff --git a/ELF/README.md b/ELF/README.md</div><div>index 49b8167..b71faf4 100644</div><div>--- a/ELF/README.md</div><div>+++ b/ELF/README.md</div><div>@@ -19,3 +19,16 @@ Achieving good performance is one of our goals. It's too early to reach a</div><div> conclusion, but we are optimistic about that as it currently seems to be faster</div><div> than GNU gold. It will be interesting to compare when we are close to feature</div><div> parity.</div><div>+</div><div>+Library Use</div><div>+-----------</div><div>+</div><div>+You can embed LLD to your program by linking against it and calling the linker's</div><div>+entry point function lld::elf2::link.</div><div>+</div><div>+The current policy is that it is your reponsibility to give trustworthy object</div><div>+files. The function is guaranteed to return as long as you do not pass corrupted</div><div>+or malicious object files. A corrupted file could cause a fatal error or SEGV.</div><div>+That being said, you don't need to worry too much about it if you create object</div><div>+files in a usual way and give it to the linker (it is naturally expected to</div><div>+work, or otherwise it's a linker's bug.)</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 3:21 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Feb 2, 2016 at 3:04 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm going to add to the linker.<div><pre style="color:rgb(0,0,0)">+// Entry point of the ELF linker. Returns true on success. It is
+// guaranteed to return as long as you do not pass corrupted or malicious
+// object files. A corrupted file could cause a fatal error or SEGV.
+// That being said, you don't need to worry too much about it if you
+// create object files in a usual way and feed it to the linker
+// (it is naturally expected to work, or otherwise that's a linker's bug.)
 bool link(ArrayRef<const char *> Args, llvm::raw_ostream &Error = llvm::errs());</pre></div></div><div><div><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div></span><div>That sounds fine to me. I would consider adding it to README.txt instead, and to phrase it as "this is our current policy" instead of casual advice (otherwise it is difficult to use as a starting point for discussion IMO). Whatever you think makes sense though.</div><span><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 2, 2016 at 2:25 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Feb 2, 2016 at 1:42 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Feb 2, 2016 at 8:44 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Feb 1, 2016 at 11:05 PM, Sean Silva via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Feb 1, 2016 at 12:27 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.)</div></blockquote><div><br></div></span><div>You can probably find some way to set the alignment using an attribute or whatever even from clang (and without inlineasm).</div><div><br></div><div>I don't think there is a platonically-ideal answer for this. It's more about goals:</div><div>- 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).</div><div>- 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).</div></div></div></div></blockquote></span><div><br>I don't think this is a valid assumption for all programmatic users (& indeed Clang and LLVM both have ways of accepting untrusted inputs - the assumption in LLVM is "if it's not already in the in-memory representation, it's not trusted" (parsing bitcode, reading files, etc) and I think the same would probably be reasonable in lld - callers with object contents in memory (or even a higher level representation - the same as the difference between LLVM IR and LLVM bitcode in a memory buffer) can choose to have lld assume validity (if they produced it from an API they trust/are willing to bugfix if it's ever wrong) or ask for verification (if they got the object over a network connection or other untrusted source (perhaps read it out of a compressed archive, etc))). An API integration of LLD into the Clang driver wouldn't be a sound place to make this assumption - some objects may be passed to Clang (not generated by it) from some other compilation or source, for example. </div></div></div></div></blockquote><div><br></div></span><div>I think these can serve as a baseline that we can document / elaborate on down the road though.</div><div>For the moment, we can document our current intentions/policies. That way people can either a) concretely file bug reports against us for violating our intentions or b) we can have a concrete discussion on llvm-dev about changing those documented policies/intentions.</div></div></div></div></blockquote><div><br></div></span><div>Good point. We need to document the current policy whatever it is. And the current policy after I submit these pending patches is that "the linker doesn't crash or exit (or it is a bug) as long as you don't give corrupted/malicious object files." I will write that to the Driver file which all people who wants to use will see.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It seems our current situation is that any time anything related to this comes up, everybody and their dog start talking about different hypothetical situations that nobody is actively working on using LLD for (since there are other, higher priorities right now). These may or may not be true, or the parallels to clang/LLVM may or may not be true, but currently we don't have a starting point for a useful discussion. It is all ad-hoc. We need a fixed point of reference for future discussion and what I posted (in this thread and others) seems like a sweet spot to start with; it provides reasonable guarantees and avoids overcommitting our development effort at an early stage. </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I actually have points to say in response to what you said, but here in an llvm-commits discussion is not the right place to discuss it.</div><span><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- Sean Silva</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 12:11 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 1 February 2016 at 15:06, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
> On Mon, Feb 1, 2016 at 11:57 AM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> On 1 February 2016 at 14:46, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br>
>> > I think one of the main use cases that has been requested is to be able<br>
>> > to<br>
>> > programmatically call the linker with "known good" object files (i.e.<br>
>> > produced by the compiler). That simplifies things a lot. Rui's recent<br>
>> > patches that are thread_local'izing existing globals seems like a<br>
>> > satisfactory approach. Or am I missing something?<br>
>><br>
>> Yes, known good files are a lot easier to handle. We just have to be<br>
>> clear what "known good" is.<br>
>><br>
>> > The R_X86_64_REX_GOTPCRELX situation can probably be likened to someone<br>
>> > giving clang a piece of source code with an inline asm that has:<br>
>> ><br>
>> > .text<br>
>> > .byte <some garbage><br>
>> ><br>
>> > in it. We don't guarantee that the output "makes sense" because there's<br>
>> > really no way for us to know what "makes sense" in a precise way (i.e.,<br>
>> > a<br>
>> > way that we can program).<br>
>><br>
>> Would we still be required to check the offsets so we don't crash? An<br>
>> assembly file can contain<br>
>><br>
>> .reloc 0, R_X86_64_REX_GOTPCRELX, foo<br>
>> .long 4<br>
>><br>
>> which would put that relocation in an invalid location. In general, is<br>
>> an arbitrary assembly file to be considered "known good"? Is that true<br>
>> even for things like<br>
>><br>
>> .section .eh_frame, ....<br>
>> garbage<br>
>><br>
>> that the linker has to parse?<br>
><br>
><br>
> I think the answer is case-by-case, but I don't think we have to guarantee<br>
> to recover from errors caused by carefully-crafted malicious object files.<br>
> (Is there anyone who disagrees with that?)<br>
<br>
</div></div>It is definitely not a use case *I* have an interest in. I just want<br>
to be an agreement on what use case we want to support at the moment.<br>
Is it "any .o file", "any llvm-mc or gas produced .o", "any clang or<br>
gcc produced .o not including inline asm"?<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
<br></div></div><span>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></span></blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>