install asan libs to out directory so root is not needed #380
Comments
|
I don't understand how 2 happened. The library isn't versioned on the device, so the loader should just pick up the unversioned one. |
|
Actually android-ndk-r14b/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/3.8.275480/lib/linux/libclang_rt.asan-arm-android.so |
$ readelf -sW android-ndk-r14b/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/3.8.275480/lib/linux/libclang_rt.asan-arm-android.so | grep __android_log_write
29: 00000000 0 FUNC GLOBAL DEFAULT UND __android_log_write@LIBLOG (4)
26654: 00000000 0 FUNC GLOBAL DEFAULT UND __android_log_writeThat's what I'd expect, so I'm not sure why it doesn't work. I'm going to have to take a closer look, but that may not happen this week. |
|
// 64-bit Android targets don't provide the deprecated __android_log_write. That comes directly from the sources in compiler-rt (which is where the asan libraries are built), so this mismatch is expected. |
|
So, is it impossible to use ASAN for code targeted for android 4.4? Only L+? |
|
It's supposed to work with KitKat too. |
|
Then, what should I use for logging from native code if __android_log_write makes problem and syslog is only from L? |
|
|
|
How did you work around issue (1)? asan_device_setup does not work at all on Windows, except perhaps Windows 10, as the shell script does not work in Cygwin. I've been trying to get it to work from a Mac, but ran into issues there as well. The 'adb root' route didn't work. Using --use-su didn't work until I reworked the mount command to workaround argument ordering isssues with mount on Android N. After getting past this, however, I run into still more issues. Is there any reason to expect this script to work with Android N? Has it been tested/verified in recent history? Or can I just temporarily add the ASAN library to my project and build that way? If so, that's not the documentation should really posit that as an option. Right now it seems like AddressSanitizer is simply an exercise in frustration. |
We have a test for ASAN and it runs many times a day. We use What device are you using? I test with a Pixel. |
|
I am trying this on a (rooted, obviously) Nexus 9. I never figured out how to get 'adb root' to work -- else I'd have used it. |
|
Using Either way, I don't think |
|
We're tested on Nexus 5x, rooted. |
|
Definitely m+ |
|
"adb disable-verity" returns: This is for a rooted Nexus 9 tablet running Android 7.1.1. (I'm afraid to update it further as it is my understanding that this may undo the rooting -- and that was painful enough to do once...) Having to root the device to troubleshoot native memory handling is bad enough -- as it seems like there should be hooks already in place that an app can simply opt into. Not being able to get ASAN working with a rooted device is another matter. As noted above "asan_device_setup --use-su" fails rather quickly as it stands, the remount parameters have to reordered to work around issues in Android 7.x (rw,remount vs. remount,rw). After this, I get further issues -- hence my question about whether this has been tested. |
|
tbqh I'm not sure why ASAN requires root. @eugenis is the one that did all the ASAN support for Android, so hopefully he'll be able to shed some light on everything above. |
|
You are right, there should be hooks, or, generally, a way to run
applications with ASan without rooting the phone. But all we have is this
script. I've tested it with N and even O, but not the --use-su code path. I
don't know what the analogue of disable-verity is in that case. Patches are
welcome.
Root requirement comes from the fact that ASan needs to replace the memory
allocator and that requires being present in the process from the start.
There are two ways to achieve that:
1. LD_PRELOAD ASan runtime library into the Zygote. This is what the script
does.
2. Use wrap.<app name> system property to force the Zygote to fork-exec
instead of just fork when starting an app, and prepend the property value
to the command line to, again, LD_PRELOAD asan just for that app.
The second method is slower because it involves cold start of the VM for
every new process. Both methods can not be allowed on user devices because
they effectively give you root.
In theory, an apk could bring asan runtime library with it, and tell
android that it is OK with being debugged. In that case, android could
apply (2.) for this app only. This feels secure, though I'm not an expert.
This is not implemented.
…On Wed, Jun 7, 2017 at 1:07 PM, Dan Albert ***@***.***> wrote:
tbqh I'm not sure why ASAN requires root. @eugenis
<https://github.com/eugenis> is the one that did all the ASAN support for
Android, so hopefully he'll be able to shed some light on everything above.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#380 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZuSvbt8xDj3VQg54piQdLi1z_lAnhcks5sBwMRgaJpZM4NPRVv>
.
|
|
So root is only required if you want to use ASAN in the zygote, right? It's not needed for C++ executables? Since unit tests seem like the most useful place to use ASAN, we should just make that path easier. |
|
Correct. For native executables ASan is just another library.
…On Wed, Jun 7, 2017 at 2:32 PM, Dan Albert ***@***.***> wrote:
So root is only required if you want to use ASAN in the zygote, right?
It's not needed for C++ executables? Since unit tests seem like the most
useful place to use ASAN, we should just make that path easier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#380 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZuSkw-bY0WjrNq0tYSJ88cp3mMbffHks5sBxb3gaJpZM4NPRVv>
.
|
|
In my case I really want to do broad sanity checks of the C++ within an app in various overall use cases, not unit tests of the C++ by itself. Similarly, ideally the debug malloc library really shouldn't require root. Clearly the APK should have to give permission for or request this sort of meddling, but that's about it. |
This is the part that currently requires root, as implemented. @eugenis: sounds like you think this could be changed if the work got done on the platform side? Should we get a bug filed for that?
This is something we're working on, FWIW. @enh: did this get finished? |
|
Will --use-su ASAN device setup option be fixed in upcoming release or maybe some other workarounds are available? Except using engeneering AOSP build... The goal is to detect where heap corruption in shared library. |
|
I'll try to find some time, but this is lower priority than libc++ or Windows LTO. |
depends what you mean by "not implemented". in O, there is platform support for doing this: if you have a wrap.sh script in the apk and have debuggable="true" it basically does the "wrap." thing but runs your script rather than starting the child directly. yabinc and agampe know the most about it, so they'll be able to help you out. @cferris1000 is best placed to comment on the status of "ideally the debug malloc library really shouldn't require root". |
|
On Mon, Jul 10, 2017 at 1:18 PM, Elliott Hughes ***@***.***> wrote:
@eugenis <https://github.com/eugenis>
In theory, an apk could bring asan runtime library with it, and tell
android that it is OK with being debugged. In that case, android could
apply (2.) for this app only. This feels secure, though I'm not an expert.
This is not implemented.
depends what you mean by "not implemented". in O, there is platform
support for doing this: if you have a wrap.sh script in the apk and have
debuggable="true" it basically does the "wrap." thing but runs your script
rather than starting the child directly. yabinc and agampe know the most
about it, so they'll be able to help you out.
Very interesting. I'll try this later.
I've switched the order of mount arguments to "rw,remount" in LLVM r307685.
+cferris1000 is best placed to comment on the status of "ideally the debug
… malloc library really shouldn't require root".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#380 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZuSgnRPtKkVJLmixss8cPKa8hwuK1_ks5sMocTgaJpZM4NPRVv>
.
|
|
Unfortunately Android hasn't finished with the Clang update yet, and this has been holding r16 up long enough. This is going to have to wait for r17. |
|
Not that want to plug my own post; but for anyone looking to use ASan in an O production device, one can do that with currently released NDK. Note that it does require su in order to use it; however, have been told that the root requirement will go away in O MR1. |
DanAlbert
changed the title
Followed instruction at https://github.com/google/sanitizers/wiki/AddressSanitizerOnAndroid
Encountered problems:
asan_device_setup script does not working. Tried with --use-su on rooted devices:
a) LG G4s, Android 5.1.1 armeabi-v7a
b) Nexus 5X, Android 7.1.2 arm64-v8a
linking fails with -fsanitize=address for armeabi-v7a (cannot resolve __android_log_write version "LIBLOG" referenced from libclang_rt.asan-arm-android.so) while it is ok for arm64-v8a
when added manually libclang_rt.asan-aarch64-android.so to project libs got the following crash:
How to get asan log for that?
Environment Details
NDK Version: r14b
Build sytem: ndk-build
Host OS: Ubuntu 16.04
Compiler: Clang -std=c++14
ABI: arm64-v8a, armeabi-v6a
STL: gnustl
NDK API level: 19,21
Device API level: 25
The text was updated successfully, but these errors were encountered: