----- Original Message -----> From: "David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rafael Espíndola" <rafael.espindola at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" > <bruce at hoult.org> > Sent: Tuesday, March 22, 2016 10:18:03 AM > Subject: Re: [llvm-dev] Need help with code generation> On Tue, Mar 22, 2016 at 4:27 AM, Rafael Espíndola < > llvm-dev at lists.llvm.org > wrote:> > > Maybe not, but it's not impossible either - browsers manage to > > > harden themselves against malicious input and they operate in a > > > far hostile environment with many more input formats than we do. >> > It is important to note how different they are. Both Firefox and > > > Chromium have people working just to try to make them more secure. > > > Compare that with LLVM: One week ago I pointed out that your patch > > > (r263521) introduces a crash. It still hasn't been reverted or even > > > acknowledge yet. >> > > I'm not trying to shift your personal goal, or to direct the > > > features that you choose to put your time into, but I am > > > interested in project policy. >> > Why do you care about policy that is not followed? A policy saying > > > llvm should not crash on any input is as relevant as one that says > > > that clang should keep bootstrapping in under one second. >> It's pretty different when you say, essentially, that patches to > address these things are unlikely to be accepted. It doesn't seem > surprising that people wouldn't try to provide those patches and > would choose not to use the project if that's the expressed policy > of the developers on the project and doesn't line up with the needs > of other people.+1 -Hal> > So, if we stick to reality, what we have is that lld (ELF and COFF) > > > are already the most reliable parts of the toolchain. If not for > > Rui > > > and I being upfront about it most people would not even know that > > you > > > could crash it. So please, just let us keep working on the most > > > reliable part of the toolchain. >> > 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-- 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/80054e53/attachment.html>
I have a question. If there is a ELF verifier function that walks every part of an ELF file to verify that the file is sane, and if you can call that before calling LLD's function, are you guys happy with that? On Tue, Mar 22, 2016 at 6:39 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > ------------------------------ > > *From: *"David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Rafael Espíndola" <rafael.espindola at gmail.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org > > > *Sent: *Tuesday, March 22, 2016 10:18:03 AM > *Subject: *Re: [llvm-dev] Need help with code generation > > > > On Tue, Mar 22, 2016 at 4:27 AM, Rafael Espíndola <llvm-dev at lists.llvm.org > > wrote: > >> > Maybe not, but it's not impossible either - browsers manage to harden >> themselves against malicious input and they operate in a far hostile >> environment with many more input formats than we do. >> >> It is important to note how different they are. Both Firefox and >> Chromium have people working just to try to make them more secure. >> Compare that with LLVM: One week ago I pointed out that your patch >> (r263521) introduces a crash. It still hasn't been reverted or even >> acknowledge yet. >> >> >> > I'm not trying to shift your personal goal, or to direct the features >> that you choose to put your time into, but I am interested in project >> policy. >> >> Why do you care about policy that is not followed? A policy saying >> llvm should not crash on any input is as relevant as one that says >> that clang should keep bootstrapping in under one second. >> > > It's pretty different when you say, essentially, that patches to address > these things are unlikely to be accepted. It doesn't seem surprising that > people wouldn't try to provide those patches and would choose not to use > the project if that's the expressed policy of the developers on the project > and doesn't line up with the needs of other people. > > > +1 > > -Hal > > > >> >> So, if we stick to reality, what we have is that lld (ELF and COFF) >> are already the most reliable parts of the toolchain. If not for Rui >> and I being upfront about it most people would not even know that you >> could crash it. So please, just let us keep working on the most >> reliable part of the toolchain. >> >> 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 > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > 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/8c01da8e/attachment.html>
Rafael Espíndola via llvm-dev
2016-Mar-22 18:46 UTC
[llvm-dev] Need help with code generation
On 22 March 2016 at 14:36, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I have a question. If there is a ELF verifier function that walks every part > of an ELF file to verify that the file is sane, and if you can call that > before calling LLD's function, are you guys happy with that?The problem is defining what is sane. For example, if a comdat group is dropped, we never look into those sections and they can contain any garbage. Is that sane? Does it depend on where the .o is in the command line? If it is not sane, checking sanity will be a noticeable amount of extra work. If it is sane, it is a funny notion of sanity. Cheers, Rafael
On Tue, Mar 22, 2016 at 7:36 PM, Rui Ueyama <ruiu at google.com> wrote:> I have a question. If there is a ELF verifier function that walks every > part of an ELF file to verify that the file is sane, and if you can call > that before calling LLD's function, are you guys happy with that? >I'd like to get you guys opinion on this question.> On Tue, Mar 22, 2016 at 6:39 PM, Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> ------------------------------ >> >> *From: *"David Blaikie via llvm-dev" <llvm-dev at lists.llvm.org> >> *To: *"Rafael Espíndola" <rafael.espindola at gmail.com> >> *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" < >> bruce at hoult.org> >> *Sent: *Tuesday, March 22, 2016 10:18:03 AM >> *Subject: *Re: [llvm-dev] Need help with code generation >> >> >> >> On Tue, Mar 22, 2016 at 4:27 AM, Rafael Espíndola < >> llvm-dev at lists.llvm.org> wrote: >> >>> > Maybe not, but it's not impossible either - browsers manage to harden >>> themselves against malicious input and they operate in a far hostile >>> environment with many more input formats than we do. >>> >>> It is important to note how different they are. Both Firefox and >>> Chromium have people working just to try to make them more secure. >>> Compare that with LLVM: One week ago I pointed out that your patch >>> (r263521) introduces a crash. It still hasn't been reverted or even >>> acknowledge yet. >>> >>> >>> > I'm not trying to shift your personal goal, or to direct the features >>> that you choose to put your time into, but I am interested in project >>> policy. >>> >>> Why do you care about policy that is not followed? A policy saying >>> llvm should not crash on any input is as relevant as one that says >>> that clang should keep bootstrapping in under one second. >>> >> >> It's pretty different when you say, essentially, that patches to address >> these things are unlikely to be accepted. It doesn't seem surprising that >> people wouldn't try to provide those patches and would choose not to use >> the project if that's the expressed policy of the developers on the project >> and doesn't line up with the needs of other people. >> >> >> +1 >> >> -Hal >> >> >> >>> >>> So, if we stick to reality, what we have is that lld (ELF and COFF) >>> are already the most reliable parts of the toolchain. If not for Rui >>> and I being upfront about it most people would not even know that you >>> could crash it. So please, just let us keep working on the most >>> reliable part of the toolchain. >>> >>> 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 >> >> >> >> >> -- >> Hal Finkel >> Assistant Computational Scientist >> Leadership Computing Facility >> Argonne National Laboratory >> >> _______________________________________________ >> 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/d5cca713/attachment.html>