This is an archive of the discontinued LLVM Phabricator instance.

[safestack] Support safestack_call_for_usp attribute
AbandonedPublic

Authored by mlemay-intel on Apr 29 2016, 8:22 PM.

Details

Reviewers
eugenis
pcc
Summary

This patch adds support for the safestack_call_for_usp function attribute. This
attribute forces invocation of a __safestack_pointer_address function to locate
the unsafe stack pointer. Incidentally, this is already used by default for
non-X86 Android targets. The original intent of this patch was to enable
runtime libraries to use a simple, single-threaded USP during initialization and
then to switch over to using a thread-local USP at some point. It may be
necessary for some functions to be invoked both before and after that point, so
they need to support both modes of operation.

Event Timeline

mlemay-intel retitled this revision from to [safestack] Add -safe-stack-usp-init option.
mlemay-intel updated this object.
mlemay-intel retitled this revision from [safestack] Add -safe-stack-usp-init option to [safestack] Support runtime_init attribute in SafeStack pass.May 2 2016, 10:21 PM
mlemay-intel updated this object.
mlemay-intel added reviewers: pcc, eugenis.
mlemay-intel added a subscriber: llvm-commits.

Changed to rely on function attribute rather than -mllvm -safe-stack-usp-init flag.

Updated LangRef.

eugenis edited edge metadata.Oct 20 2016, 12:41 PM

Do you really need all this complexity, and even a magic function attribute (which is btw entirely safestack-specific, so should have "safestack" in the name)?

We've had the same problem on Android, and were able to solve it entirely on the libc side:
https://android-review.googlesource.com/#/c/170988/23/linker/linker_main.cpp

Alternatively, consider moving this code into a runtime library function. Then SafeStack instrumentation would just call a function in the prologue instead of reading from a global. This would be good for code size.

mlemay-intel edited edge metadata.

Changed name of attribute to safestack_call_for_usp.
Invoke a __safestack_pointer_address function instead of generating inline code to select and access multiple USPs.

mlemay-intel retitled this revision from [safestack] Support runtime_init attribute in SafeStack pass to [safestack] Support safestack_call_for_usp attribute.Oct 24 2016, 4:11 PM
mlemay-intel updated this object.

Do you really need all this complexity, and even a magic function attribute (which is btw entirely safestack-specific, so should have "safestack" in the name)?

You're correct that there are simpler ways to handle runtime initialization. I have been able to modify musl libc to successfully initialize based on this revised patch. I also no longer need D19853. I use -force-attribute instead.

We've had the same problem on Android, and were able to solve it entirely on the libc side:
https://android-review.googlesource.com/#/c/170988/23/linker/linker_main.cpp

I'll try to move initialization of a basic thread control block containing the USP early enough in musl libc to avoid the need for this patch. I'll report back after I've had a chance to try that.

Alternatively, consider moving this code into a runtime library function. Then SafeStack instrumentation would just call a function in the prologue instead of reading from a global. This would be good for code size.

This revised patch uses the existing code that calls out to __safestack_pointer_address.

mlemay-intel abandoned this revision.Oct 25 2016, 8:25 PM

I was able to setup a temporary thread control block early enough in musl libc initialization to obviate the need for this patch.