[llvm-dev] Need help with code generation

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 21 17:40:30 PDT 2016


> On Mar 21, 2016, at 5:27 PM, Rafael EspĂ­ndola via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> .
> >
> >
> > That boundary is usually user input. We assume that the program's memory hasn't been compromised, but anything the user puts in should be treated with suspicion. Would you use a browser that didn't check for buffer overruns?
> >
> > Part of the problem is that we assume the linker is being used in a context where the input can be trusted. A lot of the time that's true, but assuming it limits the contexts in which LLD could be used. For example, you couldn't use LLD as the linker in a build-farm if it crashed on malformed input - what's to stop someone uploading a malformed ELF file and tricking the linker into sniffing other projects being built on the same server? 
> >
> 
> You cannot possibly use llvm or lld in an adversarial situation. Cherry picking a few bugs to fix will not change that.
> 
> So my position is not that I don't want to trade run time performance for safety. My points are
> 
> * 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 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.

-- 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/f257a9af/attachment.html>


More information about the llvm-dev mailing list