[PATCH] D25467: [ELF] - Alternative fix to prevent possible crash on large output.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 13 11:36:41 PDT 2016


On Wed, Oct 12, 2016 at 2:03 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> grimar added a comment.
>
> In https://reviews.llvm.org/D25467#567497, @ruiu wrote:
>
> > The new functions seem too complicated. There are a lot of ways to crash
> the linker by giving incorrect input. We deliberately ignore some cases
> such as relocations having too large values. Why do you want to fix this
> specifically? This is not even the only place where overflow can happen. I
> think we should leave it as is.
>
>
> I am not fixing this specifically, I am trying to fix every crash or hang
> I see during AFL runs. There is no high or low priority for me, each crash
> is a problem I think.
>

No it's not. As I mentioned and as written in the document, we don't harden
the linker against all possible corrupted input files. Particularly we
deliberately ignore errors (or "trust inputs") inside very hot loops. That
means even if you add a lot of checks at various places, you can still
crash the linker. Rigorously checking input errors at some parts of the
linker and ignore errors at other places in the same linker doesn't make
much sense. That's what I was trying to say in the other thread, too.

I'm not against showing user-friendly error messages for obvious and
possible errors if doing so is easy and cheap. Notice "if" -- it needs
justification and prioritization.

Honestly, printing user-friendly errors for corrupted inputs is not that
high priority (even though it's a good thing to do). If you are looking for
stuff to work for the linker, let's discuss. I think we have to-do items
that are waiting for us to be solved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161013/63249648/attachment.html>


More information about the llvm-commits mailing list