[llvm-dev] Need help with code generation

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce Hoult" <bruce at hoult.org>
> Sent: Monday, March 21, 2016 8:24:16 PM
> Subject: Re: [llvm-dev] Need help with code generation
> 
> >> 
> >> * I don't want to trade my time implementing stuff users will see
> >> (linker script, debug index, speed) for things users will not.
> > 
> > 
> > Don't you think that you are somehow trading your time for other
> > people's time when they'll have to build other features on top of
> > the codebase?
> > I understand you're putting the cursor toward end-users facing
> > interface, but the reason I'm working on clang/LLVM in the first
> > place is especially that care is given to what other developers
> > will have to cope with in the project (while being somehow
> > pragmatic as well to make forward progress "quickly").
> 
> I don't think I am trading other developers time in this. You can
> make that argument for things like global state (I still think the
> way we are doing it is more developer time efficient overall), but I
> don't think so for security.
> 
> >> * I don't want to pretend that cherry picking a few bound checks
> >> will make lld safe on untrusted input.
> > 
> > My impression is that there is a kind of "philosophical" view at
> > stand: are we treating such crash as bugs and prioritize fixing
> > them accordingly or not. I believe we had the same kind of
> > philosophical disagreement with the development practices (no
> > global state, etc.) a few months ago: while acknowledging that
> > "perfect is the enemy of good", some long-term core principles can
> > be set, and the development can tend toward these design goals,
> > while still having some tradeoff for "getting things done" in a
> > reasonable time.
> > 
> 
> I don't really think it is philosophical. Llvm is utterly
> inappropriate for a security context on its own. You need to get
> help from the OS or something like NaCl. Take a quick look at the
> work that went into securing libressl and imagine the same being
> done to llvm.

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

 -Hal

> With security out of the way, the question that remains is how
> visible a given issue is. It is critical for clang to handle broken
> code, since it is given broken code all the time. In an IDE it gets
> it almost at every keystroke.
> 
> It less important to gracefully handle things like the example I
> posted, just because it is far less likely to be hit.
> 
> A broken object file is orders of magnitude less likely.
> 
> Cheers,
> Rafael
> _______________________________________________
> 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