<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 01/03/2017 04:55 PM, Chandler
Carruth via cfe-dev wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KhcoVRqoNX8XMbR0JipbKfXR2JHuAZDCmZ3P2WRLKerTQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Jan 3, 2017 at 2:46 PM Friedman, Eli
via cfe-dev <<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
"memcpy, memmove, etc." seems to be hiding some details
here; do you<br class="gmail_msg">
have a complete list of functions you want to special-case?
There are a<br class="gmail_msg">
lot of functions which could potentially go on that list,
and some of </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">them are
POSIX or GNU extensions.<br class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>The only ones I'm immediately concerned with are the mem*
and str* functions which accept an explicit size argument
governing the pointers. I would be happy to restrict it
further if that helps.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Why do we
care about keeping these null pointer checks in particular,
as<br class="gmail_msg">
opposed to providing a flag which stops the optimizer from
deleting null<br class="gmail_msg">
pointer checks in general (like gcc's
-fno-delete-null-pointer-checks).<br class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>There are two reasons really.</div>
<div><br>
</div>
<div>First is pragmatic: all of the security vulnerabilities I
happen to be aware of stem from deleting null pointer checks
around the mem* functions, and the functions that LLVM's own
intrinsics specify null pointers as allowed for are the mem*
functions. Thus they seem likely to be the most risky.
Certainly, there are security issues stemming from other
null checks being eliminated, but in a purely pragmatic
sense, these seems like a useful first step.</div>
<div><br>
</div>
<div>Second is perhaps more interesting. I think there are a
large number of null pointer checks that we can and should
eliminate. I'll give one example here of an entire class:
references to objects with non-zero size. Taking the address
of this cannot produce a null pointer, and code checking for
null I think should be optimized away IMO.</div>
<div><br>
</div>
<div>There is something very special about the nature of the
mem* intrinsics and that is that they can accept a *zero*
size. It is that zero size case that I think makes a null
pointer a reasonable argument to them. I would like to
suggest that whenever we have a pointer and size where the
size could reasonably be zero, the pointer could also
reasonably be null.</div>
<div><br>
</div>
<div>While this will cover some number of the current uses of
nonnull attribute, I think there are a reasonably large
number of other uses that I'm not sure such sweeping
statements can be made about. With a reference to a non-zero
sized object, I don't see any reason to eliminate the
nonnull attribute or to stop optimizing away. Indeed, the
way these occur in C++ as part of the *type system* can make
this an incredibly important optimization in conjunction
with proper inlining.</div>
<div><br>
</div>
<div>I'm not really opposed to having a mode that disables
*all* non-null optimizations, but I think that is a very
different thing and I'm personally much less interested in
such a mode. I don't think we could reasonably make that the
default for example, whereas I think we could reasonably
drop these particular nonnull attributes from glibc headers
by default.</div>
</div>
</div>
</blockquote>
<br>
I agree with this. -fno-delete-null-pointer-checks is too heavy a
hammer to ideally address this problem. We can and should provide a
more-targeted solution (regardless of whether it is on by default).<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAGCO0KhcoVRqoNX8XMbR0JipbKfXR2JHuAZDCmZ3P2WRLKerTQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>-Chandler</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>