[llvm-dev] Need help with code generation

[Lang Hames via llvm-dev]

Hi Rafael,


> It is really annoying how much people care about "security" to criticize
> my work,


FWIW it was never my intention to criticize your work. I think your work is
amazing, and I hope you continue. What I've taken issue with is the policy
stance. I think LLVM projects should aim for robustness even knowing
they're going to fall short, because I think there is a real difference
between a project which can be easily exploited, and one that takes effort
to exploit.


Would it end this thread if I went that way? Just say that there are
>
> bugs in lld and just not fix them for over a year?
>
>

> It would make a big difference if it was "Yes, these are bugs but not high
> priority for the current/active contributors to invest time in fixing (but
> happy to review patches to fix them, etc)" versus "these are not bugs/it's
> highly unlikely we'd accept patches to fix them".


+1

Cheers,
Lang.


On Tue, Mar 22, 2016 at 11:54 AM, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Tue, Mar 22, 2016 at 11:43 AM, Rafael Espíndola <
> llvm-dev at lists.llvm.org> wrote:
>
>> >
>> > This is a completely inappropriate comparison. LibreSSL is a
>> cryptographic library. Creating a high-quality cryptographic library
>> requires much more than eliminating buffer overruns (etc.).
>>
>> What I don't get this what is the point of a "somewhat secure". Does
>> it make a difference if takes 5 minutes of 5 hours to find a buffer
>> overflow?
>>
>> >> What allocator would you start with?
>> >>
>> >
>> > We recently had a bunch of patches fixing issues found when fuzz
>> testing LLVM with ASAN, and I thought that was a very positive development.
>> >
>>
>> And today it is still way easier to crash llvm than lld. I posted two
>> crashes with just what I noticed going on the list.  No one even
>> posted an ELF that would crash lld.
>>
>
> No, we were responding to the stated policy that it's intentional that LLD
> would crash/UB on certain inputs. We're debating that policy/intention.
>
>
>> It is really annoying how much people care about "security" to
>> criticize my work, but never enough to send a patch. llvm.org/pr21466
>> is open since Nov 2014. That is on the side of the project that should
>> be handling broken files.
>
>
>> Would it end this thread if I went that way? Just say that there are
>> bugs in lld and just not fix them for over a year?
>>
>
> It would make a big difference if it was "Yes, these are bugs but not high
> priority for the current/active contributors to invest time in fixing (but
> happy to review patches to fix them, etc)" versus "these are not bugs/it's
> highly unlikely we'd accept patches to fix them".
>
> Across the project we certainly prioritize bugs based on impact to those
> who are involved - we tend to fix Clang crash-on-valid faster than
> crash-on-invalid (certainly Kostya's been frustrated by lack of traction on
> some of the fuzzer findings - because few people need a security hardened
> LLVM/Clang, but generally "doesn't crash" is considered to be a
> valid/accepted goal, even if it's not hardened). Some bugs impact some
> users more than others, so are more important to some developers. 'tis the
> way of things.
>
> - Dave
>
>
>>
>> Cheers,
>> Rafael
>> _______________________________________________
>> 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/20160322/416d7a15/attachment.html>