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: "Lang Hames via llvm-dev" <llvm-dev at lists.llvm.org> > To: "David Blaikie" <dblaikie at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org> > Sent: Tuesday, March 22, 2016 1:57:10 PM > Subject: Re: [llvm-dev] Need help with code generation > > > > 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. >+1> > 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+1 -Hal> > > 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 > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
David Blaikie via llvm-dev
2016-Mar-22 20:04 UTC
[llvm-dev] Need help with code generation
On Tue, Mar 22, 2016 at 12:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Lang Hames via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "David Blaikie" <dblaikie at gmail.com> > > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org > > > > Sent: Tuesday, March 22, 2016 1:57:10 PM > > Subject: Re: [llvm-dev] Need help with code generation > > > > > > > > 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. > > > > +1 >Agreed - it's great that a linker is being produced that's fast and carefully implemented, etc. There just seems to be some disagreement about what the best tradeoffs are.> > > > > 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 > > +1 > > -Hal > > > > > > > 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 > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/510b64b0/attachment.html>
Chris Bieneman via llvm-dev
2016-Mar-22 20:15 UTC
[llvm-dev] Need help with code generation
> 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>
Rafael Espíndola via llvm-dev
2016-Mar-22 20:27 UTC
[llvm-dev] Need help with code generation
On 22 March 2016 at 16:15, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > 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. >My last email on this thread or on the subject at all ever is to once more point out that we have fewer crashes than llvm, so calling something a bug doesn't seem to have the magical properties that are implied. I will be improving our relocation processing to make it faster and more obviously correct for valid inputs. That is what I see as quality. If you think lld doing this or that on a hexedit creation should be called a bug or any other name, you can call it that, but it will not influence what I work on. Cheers, Rafael