[llvm-dev] Need help with code generation

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 21 18:36:29 PDT 2016


Hi Rui, Rafael,

You cannot possibly use llvm or lld in an adversarial situation. Cherry
> picking a few bugs to fix will not change that.


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.

So my position is not that I don't want to trade run time performance for
> safety.


That's a fundamental shift from current LLVM policy as I understand it.

I don't really think it is philosophical. Llvm is utterly inappropriate for
> a security context on its own.


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

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.


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.

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.

Cheers,
Lang.

On Mon, Mar 21, 2016 at 6:24 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

>
> >>
> >> * 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. What allocator would you
> start with?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/dc6e37c5/attachment.html>


More information about the llvm-dev mailing list