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

[George Rimar via llvm-commits]

> 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.

>
Generally I think there is no much places that can crash the linker. When invalid input just produce invalid output it is fine situation that we are not trying to fix, crash is bit different though. No need to touch hot loops to fix them I believe. Few numbers:
I am running AFL for about 3.5 days for now and it is at 87% atm (using ouputs from fuzzing bug page as inputs). It found 36.3k crashes (189 unique). That is how it shows. At fact 189 here is about 3-4-5 patches, so many of crashes are different path for the same crash point usually.
Overflow of FileSize calculation and crash in writeTo is huge amount portion of observed crashes. At least seems this overflow can not be exploited I think (though I am not really sure here).

>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.

Let's discuss.
What to-do items you have in mind ?

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161014/c3ecfb0a/attachment.html>