<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/9/13 5:24 PM, Nick Lewycky wrote:<br>
</div>
<blockquote
cite="mid:CADbEz-j7uCOYLOes_tKDTUYNXGYgaEA4rugBa_PRL5vy6a-87g@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">[snip].<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"> <br>
</div>
Briefly looking at ASAN again, I saw a performance penalty
of 2x mentioned. Diversity could act as both defense in
depth, and as a lower-impact defense for performance
critical code.</blockquote>
<div><br>
</div>
<div>Okay, I've been thinking about what I wanted answered
here, and I've decided that what I want to know is too
complex for this discussion. It boils down to: given we
have all the power of clang and llvm for very complex
analysis, both static and dynamic, why is randomizing the
best we can do? Can't we somehow use all that static and
dynamic analysis to shrink the problem down to something
we can solve more cleverly than randomizing the program
across a lot of axes, such as proving (or arranging for)
certain properties which reduce how much we need to
randomize, etc? And if not *why can't we*? It's that last
part which I think is hardest to answer, so I've decided
I'll leave this to the security-trained folks -- if they
think this is the right approach, they're probably right.</div>
</div>
</div>
</div>
</blockquote>
<br>
You are right that, with LLVM and Clang's facilities, we can do
better. However, in my opinion, the cost of many of these solutions
is still too high (both in terms of development cost and run-time
performance) for industry to accept them. I am also of the opinion
that many people do not understand the options that are available,
partially because the work on the subject is spread across 4
different communities (compiler, operating systems, security, and
software engineering).<br>
<br>
Automatic, very strong memory safety guarantees are hard to enforce
on existing C code with good efficiency. It can be done, but it
requires sophisticated analyses (e.g., type-inferencing,
whole-program points-to analysis) and, therefore, requires a decent
level of expertise and incurs significant developer cost. Industry
is also very picky about run-time performance; Vikram and I were
told once by a bay-area company that they would only use a security
solution if it added 0% run-time overhead. Such performance goals
will kill just about any solution.<br>
<br>
Enforcing a weaker property like control-flow integrity looks very
promising both in terms of development cost, performance overhead,
and security. I'm not sure why it doesn't get more attention.
Perhaps no one is yet willing to work out the remaining
compatibility issues with native code libraries, or maybe industry
wants someone else to build an open-source implementation first
before committing to further development, or maybe people simply are
unaware of what it is. I'm curious to know.<br>
<br>
If you're interested in knowing more about the topic, take a look at
the Memory Safety Menagerie at
<a class="moz-txt-link-freetext" href="http://sva.cs.illinois.edu/menagerie">http://sva.cs.illinois.edu/menagerie</a>. I need to update it since a
few new papers have come out, but it provides a good number of
papers on the subject (including quite a few that use LLVM).<br>
<br>
My two cents.<br>
<br>
-- John T.<br>
<br>
</body>
</html>