llvm dev - Mar 2016 - Need help with code generation

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

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?

Cheers,
Rafael

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/fbd75efd/attachment.html>

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>

----- Original Message -----
> From: "Rafael Espíndola" <rafael.espindola at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce
Hoult" <bruce at hoult.org>, "Mehdi Amini" <mehdi.amini
at apple.com>
> Sent: Tuesday, March 22, 2016 1:43:54 PM
> Subject: Re: [llvm-dev] Need help with code generation
> 
> >
> > 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?
I don't want to get too far off track, but I feel that there should be no
buffer overruns in LLVM. Period. Cryptographic libraries also need to be
concerned about other issues, such as information leakage, that are much harder
to verify.
> 
> >> 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.
That's because we seem to be debating whether we'd actively reject a
patch to fix such issues, not how important they are to us to fix.

Thanks again,
Hal
> 
> 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?
> 
> Cheers,
> Rafael
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

> That's because we seem to be debating whether we'd actively reject
a patch to fix such issues, not how important they are to us to fix.
I would not work on it. Including not review it while there are actual
missing features to be implemented.

If you want to call that a low priority bug, go for it. I don't find
it honest to do that myself.

Cheers,
Rafael