[PATCH] D108479: [Clang] Add __builtin_addressof_nocfi

Peter Collingbourne via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 15 11:07:51 PST 2021


pcc added a comment.

In D108479#3129577 <https://reviews.llvm.org/D108479#3129577>, @rjmccall wrote:

> In D108479#3129571 <https://reviews.llvm.org/D108479#3129571>, @jrtc27 wrote:
>
>> For CHERI there's the added complication that descriptors and trampolines can exist for security reasons when crossing security domains, and you absolutely should not let one compartment get pointers to the entry point of another compartment's function. You can hand it out if sealed or the permissions are cleared, as then you can't really do anything with it other than look at the integer address, but that seems a bit odd.
>
> That would be consistent with getting an unsigned pointer under pointer authentication or an address with the THUMB bit potentially stripped: it's just a raw address that you can't safely call.  In any case, I suspect it would be fine for us to say that we just don't support this builtin when the target is using weird function pointers unless we have some way to bypass the special treatment in LLVM.
>
> I agree that "symbol" address is probably the wrong name.  Maybe `__builtin_function_start` or something like that?  But before we go much further on this, we should get confirmation from Peter that we're targeting the right design.

Having this be defined to return the function body address (and diagnose at compile time if that's not supported) seem like the right design to me, and  `__builtin_function_start` sounds like a good name.

Here's another example of a potential use case that came up in the course of the PAuth ABI work: testing whether a stack trace contains a particular function:
https://cs.android.com/android/platform/superproject/+/master:bionic/tests/execinfo_test.cpp;l=94

I think that no matter whether it's CFI, PAuth, CHERI or anything else, this test would want the address of the real function body. If the test is compiled on a platform where taking the real function body address is unsupported, it would fail at runtime if we just let this be compiled as a no-op, so we should diagnose the issue at compile time where possible.



================
Comment at: clang/test/SemaCXX/builtins.cpp:44
+void a(void) {}
+static_assert(__builtin_addressof_nocfi(a) == a, "");
+
----------------
I don't think this should always evaluate to true, should it? Maybe we should forbid these types of comparisons in integral constant expressions?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108479/new/

https://reviews.llvm.org/D108479



More information about the cfe-commits mailing list