<div dir="ltr">Hi Rui, Rafael,<div><span style="font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">You cannot possibly use llvm or lld in an adversarial situation. Cherry picking a few bugs to fix will not change that.</span></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">So my position is not that I don't want to trade run time performance for safety. </span></blockquote><div><span style="font-size:13px"><br></span></div><div>That's a fundamental shift from current LLVM policy as I understand it.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">I don't really think it is philosophical. Llvm is utterly inappropriate for a security context on its own.</span></blockquote><div><br></div></div><div>You're framing security as binary: something is either 100% secure, or fundamentally insecure. As far as I know that's not how other projects deal with the security, and I don't see why LLVM is special here. I'd be pretty upset with my word-processor if I found it their project policy on trivially malformed input allowing arbitrary execution was "works correctly".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">Our goal as a whole is, as I believe, to provide value to users, and LLD development speed is accelerating and it is about to be providing real (and possibly large) values to users.</span></blockquote><div><br></div><div>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. As policy, tools should not crash on user input: this is unfriendly to users at best and a potential attack vector at worst. I don't know of any other large projects (even command line tools) where it would be considered ok to just crash (as opposed to exit(1)) on bad input.</div><div><br></div><div>Anyway - I think we're still stuck with "agree to disagree" for now. Having put in my 2 cents (and then some) I'm happy to bow out for now.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 21, 2016 at 6:24 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
>><br>
>> * I don't want to trade my time implementing stuff users will see (linker script, debug index, speed) for things users will not.<br>
><br>
><br>
> 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?<br>
> 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").</p>
</span><p dir="ltr">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.</p><span class="">
<p dir="ltr">>> * I don't want to pretend that cherry picking a few bound checks will make lld safe on untrusted input.<br>
><br>
> 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.<br>
></p>
</span><p dir="ltr">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. What allocator would you start with?</p>
<p dir="ltr">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.</p>
<p dir="ltr">It less important to gracefully handle things like the example I posted, just because it is far less likely to be hit.</p>
<p dir="ltr">A broken object file is orders of magnitude less likely.</p>
<p dir="ltr">Cheers,<br>
Rafael</p>
</blockquote></div><br></div>