llvm dev - Mar 2016 - Need help with code generation

We do not enable exceptions and longjmp is not safe. Also, if it can
segfault for some pathetic input, "it longjmps in most cases"
doesn't help
people who wants 100% guarantee like you.

On Mon, Mar 21, 2016 at 8:21 PM, James Molloy <james at jamesmolloy.co.uk>
wrote:
> If it can exit, why can't it longjmp back to a library consumer at
least?
>
> On Mon, 21 Mar 2016 at 19:20 Rui Ueyama <ruiu at google.com> wrote:
>
>> On Mon, Mar 21, 2016 at 8:16 PM, James Molloy <james at
jamesmolloy.co.uk>
>> wrote:
>>
>>> > Correct
>>>
>>> Out of interest, how does LLD itself handle error reporting when
invoked
>>> from the command line, and how does it avoid segfaulting in that
case?
>>>
>>
>> It generally reports an error and exit, or in rare circumstances it
just
>> segfaults.
>>
>>
>>> Cheers,
>>>
>>> James
>>>
>>> On Mon, 21 Mar 2016 at 19:14 Rafael Espíndola <
>>> rafael.espindola at gmail.com> wrote:
>>>
>>>> On 21 March 2016 at 15:10, James Molloy <james at
jamesmolloy.co.uk>
>>>> wrote:
>>>> > Well sure, it's unlikely, but how many consumers can
make that sort of
>>>> > guarantee? And if a consumer can't guarantee the
integrity of the ELF
>>>> file
>>>> > they have no choice but not to use LLD, or to fork before
using it.
>>>>
>>>> Correct.
>>>>
>>>> Cheers,
>>>> Rafael
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/583ed852/attachment.html>

> Also, if it can segfault for some pathetic input
Surely that's a bug though, not seriously designed behaviour?

On Mon, 21 Mar 2016 at 19:24 Rui Ueyama <ruiu at google.com> wrote:
> We do not enable exceptions and longjmp is not safe. Also, if it can
> segfault for some pathetic input, "it longjmps in most cases"
doesn't help
> people who wants 100% guarantee like you.
>
> On Mon, Mar 21, 2016 at 8:21 PM, James Molloy <james at
jamesmolloy.co.uk>
> wrote:
>
>> If it can exit, why can't it longjmp back to a library consumer at
least?
>>
>> On Mon, 21 Mar 2016 at 19:20 Rui Ueyama <ruiu at google.com>
wrote:
>>
>>> On Mon, Mar 21, 2016 at 8:16 PM, James Molloy <james at
jamesmolloy.co.uk>
>>> wrote:
>>>
>>>> > Correct
>>>>
>>>> Out of interest, how does LLD itself handle error reporting
when
>>>> invoked from the command line, and how does it avoid
segfaulting in that
>>>> case?
>>>>
>>>
>>> It generally reports an error and exit, or in rare circumstances it
just
>>> segfaults.
>>>
>>>
>>>> Cheers,
>>>>
>>>> James
>>>>
>>>> On Mon, 21 Mar 2016 at 19:14 Rafael Espíndola <
>>>> rafael.espindola at gmail.com> wrote:
>>>>
>>>>> On 21 March 2016 at 15:10, James Molloy <james at
jamesmolloy.co.uk>
>>>>> wrote:
>>>>> > Well sure, it's unlikely, but how many consumers
can make that sort
>>>>> of
>>>>> > guarantee? And if a consumer can't guarantee the
integrity of the
>>>>> ELF file
>>>>> > they have no choice but not to use LLD, or to fork
before using it.
>>>>>
>>>>> Correct.
>>>>>
>>>>> Cheers,
>>>>> Rafael
>>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/b0cef143/attachment.html>

On Mon, Mar 21, 2016 at 8:25 PM, James Molloy <james at jamesmolloy.co.uk>
wrote:
> > Also, if it can segfault for some pathetic input
>
> Surely that's a bug though, not seriously designed behaviour?
>
No. That is a design choice.

> On Mon, 21 Mar 2016 at 19:24 Rui Ueyama <ruiu at google.com> wrote:
>
>> We do not enable exceptions and longjmp is not safe. Also, if it can
>> segfault for some pathetic input, "it longjmps in most cases"
doesn't help
>> people who wants 100% guarantee like you.
>>
>> On Mon, Mar 21, 2016 at 8:21 PM, James Molloy <james at
jamesmolloy.co.uk>
>> wrote:
>>
>>> If it can exit, why can't it longjmp back to a library consumer
at least?
>>>
>>> On Mon, 21 Mar 2016 at 19:20 Rui Ueyama <ruiu at google.com>
wrote:
>>>
>>>> On Mon, Mar 21, 2016 at 8:16 PM, James Molloy <james at
jamesmolloy.co.uk>
>>>> wrote:
>>>>
>>>>> > Correct
>>>>>
>>>>> Out of interest, how does LLD itself handle error reporting
when
>>>>> invoked from the command line, and how does it avoid
segfaulting in that
>>>>> case?
>>>>>
>>>>
>>>> It generally reports an error and exit, or in rare
circumstances it
>>>> just segfaults.
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> James
>>>>>
>>>>> On Mon, 21 Mar 2016 at 19:14 Rafael Espíndola <
>>>>> rafael.espindola at gmail.com> wrote:
>>>>>
>>>>>> On 21 March 2016 at 15:10, James Molloy <james at
jamesmolloy.co.uk>
>>>>>> wrote:
>>>>>> > Well sure, it's unlikely, but how many
consumers can make that sort
>>>>>> of
>>>>>> > guarantee? And if a consumer can't guarantee
the integrity of the
>>>>>> ELF file
>>>>>> > they have no choice but not to use LLD, or to fork
before using it.
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>> Cheers,
>>>>>> Rafael
>>>>>>
>>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/5fc496a0/attachment.html>

> On Mar 21, 2016, at 2:20 PM, James Molloy via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Rafael,
> 
> How can a high quality product crash by design? I understand the lack of
structured error handling, and I understand asserting (which in release mode
would be silent) on internal errors. But on an input? How can an application be
taken seriously when crashes are design features?
> 
> And I certainly didn't see consensus or in fact the suggestion of this
in the other thread, unless I glazed over an important part.
My understanding is that clang and llvm themselves are designed this way (crash
when the unexpected happens). For example the fact that clang forks itself to be
able to report diagnostics is a good indication that this is assumed, and llvm
is full of report_fatal_error() (or worse, assertions that can fire on
unexpected user input).
I complained on the list at some point that "by design" LLVM as a
library requires you to fork and run in a separate process, but the tradeoff in
the ease of implementation seems to be the current consensus.

-- 
Mehdi




> 
> James
> On Mon, 21 Mar 2016 at 21:16, Rui Ueyama <ruiu at google.com
<mailto:ruiu at google.com>> wrote:
> Of course I'm not happy. And I hope that you understood that that is
unusual. Having said that, I'd say it's however reasonable.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/8fbdd24b/attachment.html>

On Mon, Mar 21, 2016 at 2:27 PM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> On Mar 21, 2016, at 2:20 PM, James Molloy via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Rafael,
>
> How can a high quality product crash by design? I understand the lack of
> structured error handling, and I understand asserting (which in release
> mode would be silent) on internal errors. But on an input? How can an
> application be taken seriously when crashes are design features?
>
> And I certainly didn't see consensus or in fact the suggestion of this
in
> the other thread, unless I glazed over an important part.
>
>
> My understanding is that clang and llvm themselves are designed this way
> (crash when the unexpected happens). For example the fact that clang forks
> itself to be able to report diagnostics is a good indication that this is
> assumed, and llvm is full of report_fatal_error() (or worse, assertions
> that can fire on unexpected user input).
>
So far as I know, any place where LLVM asserts on user input is a bug -
maybe not a high priority bug in some cases, maybe a difficult bug in some
cases, but a bug.

report_fatal_error is a bit of a wart, to be sure (but that's more along
the lines of the previous LLD design thread - API level error handling V
exit(1) from deep in the library*)

* I didn't understand the previous LLD therad to include the possibility of
crash/assert by design, but exit(1) by design V return error codes up the
stack - the latter is what I thought that thread was about.

> I complained on the list at some point that "by design" LLVM as a
library
> requires you to fork and run in a separate process, but the tradeoff in the
> ease of implementation seems to be the current consensus.
>
The forking in a separate process is, so far as I understand, simply a
necessary defensive measure for certain products - we accept that LLVM has
bugs that may lead it to crash, so we want crash reports when that happens.
The fact that we report the crashes and fix them seems to indicate that
they're not by design. If the fork was simply to swallow (rather than
report) the crashes, then it would seem to indicate crash-by-design, but it
isn't.

- David

>
> --
> Mehdi
>
>
>
>
>
>
> James
> On Mon, 21 Mar 2016 at 21:16, Rui Ueyama <ruiu at google.com> wrote:
>
>> Of course I'm not happy. And I hope that you understood that that
is
>> unusual. Having said that, I'd say it's however reasonable.
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/1ea398eb/attachment-0001.html>

> My understanding is that clang and llvm themselves are designed this way
> (crash when the unexpected happens).
I don't think so. I'd view any Clang crash as a bug (probably to be
prioritised below silent CodeGen and many others, but not "working as
designed").
> For example the fact that clang forks itself to be able to report
diagnostics
That seems like just trying to make our own job easier to me. I think
the entire point of the fork is to get a backtrace we can fix, and
point out where the user should send it.
> llvm is full of report_fatal_error() (or worse, assertions that can fire on
unexpected user input).
A bit of a grey area since LLVM isn't itself a user-facing tool, but I
think I'd still say that a report_fatal_error that's not actionable by
the user is actually an LLVM bug. And a segfault definitely so.

Cheers.

Tim.

> On Mar 21, 2016, at 1:11 PM, Rui Ueyama via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Mon, Mar 21, 2016 at 8:57 PM, Tim Northover <t.p.northover at
gmail.com <mailto:t.p.northover at gmail.com>> wrote:
> >> You say this was decided in a thread recently- could you please
point me
> >> at that? I find this really hard to believe.
> >
> > Please find it yourself, that was a long thread.
> 
> Not helpful. The thread appears to be available here:
> http://comments.gmane.org/gmane.comp.compilers.llvm.devel/92955
<http://comments.gmane.org/gmane.comp.compilers.llvm.devel/92955>.
> 
> >The current decision was
> > not made lightly, so please respect that and take your time to
understand
> > the situation.
> 
> It was, however, made extremely controversially.
> 
> That is I guess we needed a decision. And the decision was made for not
sparking the same discussion again so soon.
It is important to mention that the "decision" (as I understood it)
was about the discussion itself going nowhere, not about settling on the state
and goals of lld itself as a LLVM project. The current state of the discussion
is AFAIK that multiple members of the community feeling strongly against the
current way, and the (non-MachO) lld developers moved on with their way despite
this opposition.

-- 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/debcdfba/attachment.html>

> On Mar 21, 2016, at 5:27 PM, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> .
> >
> >
> > That boundary is usually user input. We assume that the program's
memory hasn't been compromised, but anything the user puts in should be
treated with suspicion. Would you use a browser that didn't check for buffer
overruns?
> >
> > Part of the problem is that we assume the linker is being used in a
context where the input can be trusted. A lot of the time that's true, but
assuming it limits the contexts in which LLD could be used. For example, you
couldn't use LLD as the linker in a build-farm if it crashed on malformed
input - what's to stop someone uploading a malformed ELF file and tricking
the linker into sniffing other projects being built on the same server?
> >
> 
> You cannot possibly use llvm or lld in an adversarial situation. Cherry
picking a few bugs to fix will not change that.
> 
> So my position is not that I don't want to trade run time performance
for safety. My points are
> 
> * I don't want to trade my time implementing stuff users will see
(linker script, debug index, speed) for things users will not.
> 
Don't you think that you are somehow trading your time for other
people's time when they'll have to build other features on top of the
codebase?
I understand you're putting the cursor toward end-users facing interface,
but the reason I'm working on clang/LLVM in the first place is especially
that care is given to what other developers will have to cope with in the
project (while being somehow pragmatic as well to make forward progress
"quickly").
> * I don't want to pretend that cherry picking a few bound checks will
make lld safe on untrusted input.
> 
My impression is that there is a kind of "philosophical" view at
stand: are we treating such crash as bugs and prioritize fixing them accordingly
or not. I believe we had the same kind of philosophical disagreement with the
development practices (no global state, etc.) a few months ago: while
acknowledging that "perfect is the enemy of good", some long-term core
principles can be set, and the development can tend toward these design goals,
while still having some tradeoff for "getting things done" in a
reasonable time.

-- 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/f257a9af/attachment.html>

>>
>> * I don't want to trade my time implementing stuff users will see
(linker script, debug index, speed) for things users will
not.
>
>
> Don't you think that you are somehow trading your time for other
people's
time when they'll have to build other features on top of the
codebase?
> I understand you're putting the cursor toward end-users facing
interface,
but the reason I'm working on clang/LLVM in the first place is especially
that care is given to what other developers will have to cope with in the
project (while being somehow pragmatic as well to make forward progress
"quickly").

I don't think I am trading other developers time in this. You can make that
argument for things like global state (I still think the way we are doing
it is more developer time efficient overall), but I don't think so for
security.
>> * I don't want to pretend that cherry picking a few bound checks
will
make lld safe on untrusted input.
>
> My impression is that there is a kind of "philosophical" view at
stand:
are we treating such crash as bugs and prioritize fixing them accordingly
or not. I believe we had the same kind of philosophical disagreement with
the development practices (no global state, etc.) a few months ago: while
acknowledging that "perfect is the enemy of good", some long-term core
principles can be set, and the development can tend toward these design
goals, while still having some tradeoff for "getting things done" in a
reasonable time.
>
I don't really think it is philosophical. Llvm is utterly inappropriate for
a security context on its own. You need to get help from the OS or
something like NaCl. Take a quick look at the work that went into securing
libressl and imagine the same being done to llvm. What allocator would you
start with?

With security out of the way, the question that remains is how visible a
given issue is. It is critical for clang to handle broken code, since it is
given broken code all the time. In an IDE it gets it almost at every
keystroke.

It less important to gracefully handle things like the example I posted,
just because it is far less likely to be hit.

A broken object file is orders of magnitude less likely.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/ef7a3ff9/attachment.html>