[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

[James Y Knight via llvm-dev]

On Feb 26, 2016 8:50 PM, "Hal Finkel" <hfinkel at anl.gov> wrote:

> *From: *"James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org>
> *To: *"Sanjoy Das" <sanjoy at playingwithpointers.com>
> *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org>
> *Sent: *Thursday, February 25, 2016 1:41:43 PM
> *Subject: *Re: [llvm-dev] Possible soundness issue with
> available_externally (split from "RFC: Add guard intrinsics")
>
> 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:
>    int foo() { return 1; }
>    int bar() { return foo(); }
>
> Now, compare:
>   clang -fPIC -O1 -S -o - test.c
>   gcc -fPIC -O1 -S -o - test.c
>
> 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.
>
> 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).
>
> Is that *really* okay?
>
> 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 ;)
>

I'm not really okay with it; the current behavior feels unprincipled.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160229/5b864dae/attachment.html>