llvm dev - Mar 2016 - 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. 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/ef7a3ff9/attachment.html>

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>

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

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

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

>
> 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 I don't get this what is the point of a "somewhat secure".
Does
it make a difference if takes 5 minutes of 5 hours to find a buffer
overflow?
>> 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.
>
And today it is still way easier to crash llvm than lld. I posted two
crashes with just what I noticed going on the list.  No one even
posted an ELF that would crash lld.

It is really annoying how much people care about "security" to
criticize my work, but never enough to send a patch. llvm.org/pr21466
is open since Nov 2014. That is on the side of the project that should
be handling broken files.

Would it end this thread if I went that way? Just say that there are
bugs in lld and just not fix them for over a year?

Cheers,
Rafael