[PATCH] D16668: ELF: Remove fatal() and add the second parameter to the linker's entry point.

[David Blaikie via llvm-commits]

On Tue, Feb 2, 2016 at 8:39 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Mon, Feb 1, 2016 at 10:36 PM, Sean Silva via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>>
>>
>> On Mon, Feb 1, 2016 at 11:43 AM, Rui Ueyama <ruiu at google.com> wrote:
>>
>>> On Mon, Feb 1, 2016 at 11:18 AM, Sean Silva <chisophugis at gmail.com>
>>> wrote:
>>>
>>>> silvas added a subscriber: silvas.
>>>> silvas added a comment.
>>>>
>>>> In http://reviews.llvm.org/D16668#340546, @rafael wrote:
>>>>
>>>> > I don't think so.
>>>> >
>>>> > The problem is that we were not at 100% coverage with fatal. There
>>>> are many cases where we would just follow a broken offset and crash. If we
>>>> can produce a segmentation fault, we can call fatal.
>>>> >
>>>> > If we cannot produce a segmentation fault, we will need another way
>>>> of fixing this.
>>>>
>>>>
>>>> I think this does cover the case of programmatic invocation of LLD
>>>> (i.e., with known-good object files, which seems like the primary use case
>>>> for programmatic invocation), so it does still seem worth it.
>>>>
>>>> Bulletproofing against all possible defective object files (i.e.
>>>> guaranteeing no segfaults) is a huge amount of work I suspect (and probably
>>>> not worth it?), but this change does seem to cover a real (and requested by
>>>> many people in the community) use case.
>>>>
>>>
>>> This actually covers more than the case of programmatic invocation of
>>> LLD because my patches converted some fatals to errors which are executed
>>> only when you feed corrupted object files to the linker. As long as your
>>> object files are sane, such error handlers are unreachable.
>>>
>>> If we really want to harden the linker to not crash for any input, that
>>> makes sense to recover from such errors (but this patch is far from enough
>>> as you might imagine). Or, instead, we can set a boundary between
>>> recoverable errors (as long as your object files are not broken, we
>>> guarantee that it will never segv/exit) and unrecoverable errors (your
>>> object files must be uncorrupted/your compiler must be trustworthy). In
>>> that sense, some part of my patches doesn't make much sense -- it was
>>> aiming the middle of the two which is not a sweet spot.
>>>
>>> Hardening the linker would be a huge amount of work as Sean wrote, and
>>> it is not easy to imagine that that would worth it. It is also likely to
>>> greatly degrade runtime performance. Therefore, I think it is reasonable to
>>> choose the former policy -- caller must guarantee that the object files are
>>> not corrupted. What do you guys think?
>>>
>>
>> You mean basically:
>> - for valid object files: it is a bug in LLD if the linker crashes or
>> otherwise does not return to its caller
>> - for corrupted object files: error recovery is not guaranteed. We may
>> use fatal error handling for convenience or may even segfault.
>> ?
>>
>
> (FWIW, I think that's still going to be a transient point - we'll
> eventually want an actual API that doesn't crash.
>

Sorry, doesn't exit(). I think the idea that "if not crashing is required,
we have to harden it" is a bit more than most people are thinking of -
clang makes a an effort not to crash on user provided inputs (as does LLVM
- with the verifier, etc) but neither are "hardened" in any sense. We've
certainly recently started fuzzing them, but they've existed without that
reasonably well so far - they can certainly get better.


> The equivalent to LLVM here is that in-memory files may be trusted (in the
> same way that in-memory IR can be trusted/assumed to be verifier clean) but
> API users may still want/need to call into lld and not crash on
> uncontrolled inputs (files off disk) - in the "integrate with the clang
> driver" example, the clang driver may be driving the linker on unknown
> object files the user provided & a hard stop/exit within the API may still
> be problematic (perhaps some object files were provided and some source
> files - source files are compiled into object files, then the linker is run
> - linker hard stops on one of the user provided object files (or one of the
> generated object files is corrupted between write and read) and the
> compiler still needs to cleanup its temporary object files))
>
>
>>
>>
>
>> I think that is a sweet spot, and pretty much what LLD currently does
>> (after your recent patches land).
>>
>> Whatever we ultimately decide, it is probably worth writing it down
>> somewhere, if only to have an official reference in future discussions (it
>> will help focus future discussions I think because we will have a concrete
>> point of reference).
>>
>> -- Sean Silva
>>
>>
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160202/b552ec16/attachment.html>