[llvm-dev] Need help with code generation

Chris Bieneman via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 22 13:15:26 PDT 2016


> On Mar 22, 2016, at 11:57 AM, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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 hesitate to even pile on this thread, but Lang said something here that I felt really needed to be highlighted:

> I think LLVM projects should aim for robustness even knowing they're going to fall short,

More generally than this, my favorite thing about working on LLVM projects is that as a community we strive to very high software quality standards. Even if we don’t meet our own standards having them changes the community emphasis. I think having those standards is a huge part of why the LLVM codebase is as high quality as it is.

I hope that a commitment to general software quality is a cornerstone of LLD. Not treating all segfaults as P0 bugs is not a decision based in software quality.

-Chris


> 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 <mailto: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 <mailto: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 <http://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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/384b358a/attachment.html>


More information about the llvm-dev mailing list