<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><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" <jyknight@google.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"Sanjoy Das" <sanjoy@playingwithpointers.com>, "llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Monday, February 29, 2016 9:31:24 AM<br><b>Subject: </b>Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br><br><div dir="ltr"><p dir="ltr">On Feb 26, 2016 8:50 PM, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br></p><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><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" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>To: </b>"Sanjoy Das" <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>><br><b>Cc: </b>"llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><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><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 ;)</div></div></blockquote><div><br></div><div><p dir="ltr">I'm not really okay with it; the current behavior feels unprincipled.</p><p dir="ltr">We have a visibility attribute which can be used to control this: On ELF systems, "default" visibililty allows interposition (unlike on Darwin) -- that is, it explicitly ALLOWS for replacing the symbol's definition. The policy of "You can't replace the definition of the symbol, but it is globally visible" is exactly what the "protected" visibility mode is for.<br></p><p dir="ltr">If we want to say that you can't interpose by default on ELF targets, that would be a choice. Then, we should make the default symbol visibility "protected" instead of "default". But, continuing to generate calls through the PLT -- which is only needed because the symbols might be replaced -- while simultaneously making optimizations that are broken if they actually ARE replaced, seems kinda bogus.</p></div></div>
</div>
</blockquote>This makes sense, and I think you understand my concern here: Most programmers don't understand these issues, nor do they ever expect to use dynamic interposition. They do expect, however, that the compiler has good IPA and will use the information it is provided effectively. I'd be happy to make the default visibility protected, allowing us to continue optimizing well, and provide a principled behavior otherwise. Given, as you point out, this is the default on Darwin, is there experience from Darwin porting, or any other factors, that would indicate this would be a hardship?<br><br>Thanks again,<br>Hal<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>