https://github.com/osquery/osquery logo
Join Slack
Powered by
Hello everyone! I've updated my issue about androi...
# general
n
Hello everyone! I've updated my issue about android here : https://github.com/osquery/osquery/issues/7144#issue-913346308. Feel free to correct what seems to be wrong. I know that my post is a bit long. To sum up: if we want to use Osquery as an app (service or deamon) on Android, it is needed first to compile with the Android NDK (cross-compilation). And one of the biggest issues is that NDK (BIONIC) does not support the pthread_cancel function of gnu-libc. There is a function that BIONIC proposes as replacement (pthread_cleanup_push), but the arguments are differents, so I'm not sure whether it is possible. Thus, right now, the solution that seems to work fine, is to compile from a Linux-arm machine with static option to provide a binary that will run as a deamon in the system layer (will not run in the Java Android layer). I know that it is not functionnal for the user and it could not be a real portage solution, but it works (osqueryi and osqueryd) with some restrictions that I try to enumerate. The next step for me is to make some tables for Android. From now on, I can't go on with the NDK compilation (unless you can help me with this) @alessandrogario @Mike Myers @Stefano Bonicatti
t
You've made some great progress with this so far. I wish I could help out with the NDK exploration but it's outside of my familiarity. I suspect several of osquery's statically compiled and linked dependencies may try to use pthread_cancel. I do not believe osquery uses this directly. If this is the only blocker for using the NDK then you'll might want to isolate what code has that requirement. Keep in mind you can use your own toolchain to build osquery, you do not need to use the official osquery toolchain. We provide that mostly to provide static versions of compiler intrinsics and compatible glibc linkage for Linux OSes back to around 2011.
n
Thank you Ted! Indeed, I can get rid of these pthread_cancel errors, by avoiding import some targeted libraries. As long as these files are not needed, it solves this problem. Now there are others that I try to fix
s
For the NDK you also don't want to use the 
OSQUERY_TOOLCHAIN_SYSROOT
option, because otherwise you're mixing toolchains (or most likely compile options and include folders). It should compile only with the NDK, somewhat following the instructions that are present on their website, which talks about integrating it with CMake. I'm not sure how ideal it is to have osquery be built with the ARM toolchain; it might seem to work now but it can have all sorts of subtle issues. I would also expect the different kernel possibly not supporting the same syscalls set.
👍 1
Which is why, albeit more complex, the correct thing would be to use the NDK and reconfigure with it all the third party libraries that are needed for the tables you would like to implement/have for Android.
n
Yes. I did not put it yet in my blueprint, but I now I just do 
cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_NATIVE_API_LEVEL=21 ..
and seems to launch fine
And yes it is the way I do it now. I try to compil without any third party libraries, and at each error messages of the buld process I had the library I need (quite dum I know). So I had to add thrift, then boost etc
More precisely, I add : thrift, then boost, zlib, zstd, lzma, bzip2, icu, glog, gflags
Is it possible to get the dependency tree making by cmake just before the build process? I would like to know exactly what are the usefull dependencies for the configuration I make, and don't get the useless ones. Is it written somewhere?
s
👍 1
osquery is a big project and has many targets/libraries so the output is a bit messy, but you can filter target by target. I think you still need to look at the CMakeLists.txt specific to the table/target you're looking at
and/or look at the specific .dot file that CMake generates for that target
There's also another gotcha to be aware of, which is that unfortunately the list of libraries each target depends on is not always that precise... meaning each target and its dependencies aren't always enough to make it self standing.
A somewhat more concrete example is that, for generating osqueryd on Linux x86, let's say you need library A, B and C. Each of them has its own subtree of dependencies. Now you want to do that for Android. You know by a fact that you don't need the C library, so you remove it.. except that A and B were implicitly depending on the dependencies that C was bringing in.
It's something that we want to fix in the long run, because it's not correct, each target should be self standing and bring on its own all the dependencies it needs, but it will take a while for us to correct that. So just be aware of that ^^'.
Normally this wouldn't fly if we were building with shared libraries; you wouldn't be able to create the library A, B and C in the first place, because there's a linking step to create them. Using static libraries instead ends up having a single linking phase which is done much later, when the final osqueryd binary is built, and where all the libraries (transitively) get linked to it.
n
Ok I see. I think it is what Alessandro explained to me last time
a
if you generate the graphviz file, you can then cat | grep 'thirdparty_' to just list the deps
n
So now I am trying to compil with NDK without importing any tables. And even when I do this, the build process requires somes dependencies : thrift and boost. The problem is when I add them, it brings a lot of errors with NDK. Is it possible not import these dependencies at all? You can see above the dependencies relationship and an example with thrift*.png (extracted with graphviz)
Am I wrong with this statement : in my main_dependencies.txt file, I can see the dependencies required for osquery_main. It means each dependency is absolutely required during the building process?
s
Thrift is used to provide extensions support to osquery. I'm not sure it can be temporarily removed without changing the code. Boost is a "helper" library, much like the C++ standard library and it's used all around. It seems that you're not linking against them in CMake; when you link against their targets (thirdparty_boost for instance), they should transitively pass their include folder
n
So I imported some needed thirdparty libraries to launch th build process:
lzma, boost, bzip2, thrift, zstd and icu
I met then these errors above. Having a look on the web, it seems that monetary.h is not compatible with ndk (I am not sure yet)
Open in Slack
PreviousNext
Powered by