<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"James Y Knight via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Sanjoy Das" <sanjoy@playingwithpointers.com><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Thursday, February 25, 2016 1:41:43 PM<br><b>Subject: </b>Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br><br><div dir="ltr">While we're talking about this, I'd just mention again that the same issue arises for *normal* functions too, when linked into a shared library:<div> int foo() { return 1; }<br></div><div> int bar() { return foo(); }<br></div><div><br></div><div>Now, compare:</div><div> clang -fPIC -O1 -S -o - test.c<br></div><div> gcc -fPIC -O1 -S -o - test.c<br></div><div><br></div><div>GCC will refuse to inline foo into bar, or use any information about foo in compiling bar, because foo is exported in the dynamic symbol table, and thus replaceable via symbol interposition.</div><div><br></div><div>Clang assumes that you won't do that, or that you don't care what happens if you do. It will happily inline. And, in absense of inlining (e.g. if foo is too long to inline), clang will deduce function attributes about foo and rely on those in bar -- despite that the call goes through the PLT and could in fact be an entirely different unrelated implementation (or, for that matter, a differently-optimized version of the same implementation).</div><div><br></div><div>Is that *really* okay?</div><div id="DWT11931"><br></div></div></blockquote>I'm comfortable with saying that symbol interposition falls outside of the model we have for the targeted system (at least by default), and thus, this is okay. We also don't model the possibility of someone hex-editing the binary ;)<br><br> -Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 6:57 PM, Sanjoy Das via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi all,<br>
<br>
This is something that came up in the "RFC: Add guard intrinsics to<br>
LLVM" thread; and while I'm not exactly blocked on this, figuring out<br>
a path forward here will be helpful in deciding if we can use the<br>
available_externally linkage type to expression certain semantic<br>
properties guard intrinsics will have.<br>
<br>
Let's start with an example that shows that we have a problem (direct<br>
copy/paste from the guard intrinsics thread). Say we have:<br>
<br>
```<br>
void foo() available_externally {<br>
%t0 = load atomic %ptr<br>
%t1 = load atomic %ptr<br>
if (%t0 != %t1) print("X");<br>
}<br>
void main() {<br>
foo();<br>
print("Y");<br>
}<br>
```<br>
<br>
The possible behaviors of the above program are {print("X"),<br>
print("Y")} or {print("Y")}. But if we run opt then we have<br>
<br>
```<br>
void foo() available_externally readnone nounwind {<br>
;; After CSE'ing the two loads and folding the condition<br>
}<br>
void main() {<br>
foo();<br>
print("Y");<br>
}<br>
```<br>
<br>
and some generic reordering<br>
<br>
```<br>
void foo() available_externally readnone nounwind {<br>
;; After CSE'ing the two loads and folding the condition<br>
}<br>
void main() {<br>
print("Y");<br>
foo(); // legal since we're moving a readnone nounwind function that<br>
// was guaranteed to execute (hence can't have UB)<br>
}<br>
```<br>
<br>
If we do not inline @foo(), and instead re-link the call site in @main<br>
to some non-optimized copy (or differently optimized copy) of @foo,<br>
then it is possible for the program to have the behavior {print("Y");<br>
print ("X")}, which was disallowed in the earlier program.<br>
<br>
In other words, opt refined the semantics of @foo() (i.e. reduced the<br>
set of behaviors it may have) in ways that would make later<br>
optimizations invalid if we de-refine the implementation of @foo().<br>
<br>
The above example is clearly fabricated, but such cases can come up<br>
even if everything is optimized to the same level. E.g. one of the<br>
atomic loads in the unrefined implementation of @foo() could have been<br>
hidden behind a function call, whose body existed in only one module.<br>
That module would then be able to refine @foo() to `ret void` but<br>
other modules won't.<br>
<br>
The only solution I can think of is to redefine available_externally<br>
to mean "the only kind of IPO/IPA you can do over a call to this<br>
function is to inline it". Redefining available_externally this way<br>
will also let us soundly use it to represent calls to functions that<br>
have guard intrinsics, since a failed guard intrinsic basically<br>
replaces the function with a "very de-refined" implementation (the<br>
interpreter).<br>
<br>
What do you think? I don't think implementing the above above will be<br>
very difficult, but needless to say, it will still be a fairly<br>
non-trivial semantic change (hence I'm not directly jumping to<br>
implementation).<br>
<br>
<br>
-- Sanjoy<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>