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

[Rui Ueyama via llvm-commits]

This is a list of items that popped in my mind. Not exhaustive but probably
good enough to start discussing what we should do next.

 - FreeBSD: what is the status of building the entire FreeBSD system with
LLD? Can it build everything including the kernel?

 - OpenBSD: it is reported that the current LLD doesn't work well on their
operating system.

 - Linux: pick up a distribution and build all packages with LLD to find
out bugs and unimplemented features.

 - Unimplemented features: at least I wanted to support
--no-ctors-in-init-array.

 - Safe ICF: is there anything that we can do to support it? I don't like
the way how gold support it (e.g. recognizing ctors/dtors by mangled names,
or detecting address-taken functions by relocations) because it seems too
tricky to me. We might want to change LLVM to emit hints for linkers.

 - Parallelism: we haven't worked on this area intentionally because we are
pursuing single thread performance at this moment. But because the linker
is now fairly mature, it might be the time to start thinking about it. Is
there any place we can use multiple threads to speed up? The first thing
that comes to my mind is computing a build id using multiple threads.

- Ports: how much mature is PowerPC port? We want to support both BE and LE
PowerPCs. It's also interesting to work on an open-source ISA, RISC-V,
because the patches to support the RISC-V architecture are being merged now.

On Fri, Oct 14, 2016 at 1:39 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> > 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/20161017/cf86f8bb/attachment.html>