With the recent problems related to SSLv3 with versions of OpenSSL less than 1.0.0f, we have been investigating how to deal with this on Android for Orbot. Historically, we have used the version of OpenSSL provided by the Android device itself, which has ranged from 0.9.8 to 1.0.0e (the latest on ICS 4.0).
We have now produced a build of OpenSSL 1.0.0f with the necessary Android patches, and statically linked this into the Tor binary we ship inside of Orbot. (We already do this for LibEvent, since that is not included in Android itself). With both OpenSSL and LibEvent linked, the Tor binary increases from 3MB to about 8MB.
8MB is not terrible, but once you include the Orbot app, Privoxy and other files, we are getting into the 10MB+ range.
I think this is all fine, and we can enable users to run the app from a secured partition on their external storage, but I did just want to run this by all of you to see if there are any options for limiting the size of libssl.a and libcrypto.a, and the resulting Tor binary.
Thx!
+n8fr8
On Jan 15, 2012 9:50 AM, "Nathan Freitas" nathan@freitas.net wrote:
I did just want to run this by all of you to see if there are any options for limiting the size of libssl.a and libcrypto.a, and the resulting Tor binary.
Some stuff to try: openssl has lots of optional features and ciphers; you could probably disable a lot of them. There are configuration options to do so. If you're not sure what, I could try to take a look at the list some time this week.
Another thing to try: recent gccs and their toolchains have a trick where they can stick every function in its own segment, then tell the linker to dump the unused ones. I believe it's called "gc-segments" or something. I have no idea if it would work with openssl, but it could be worth investigating. I believe there's a ticket for tor to use it by default when possible.
Yrs,
On 15 Jan 2012, at 20:47, Nick Mathewson wrote:
Another thing to try: recent gccs and their toolchains have a trick where they can stick every function in its own segment, then tell the linker to dump the unused ones. I believe it's called "gc-segments" or something. I have no idea if it would work with openssl, but it could be worth investigating. I believe there's a ticket for tor to use it by default when possible.
I found a presentation on this which looks to contain useful information:
http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
Although post suggests that the Android NKD may have the relevant options on by default:
http://stackoverflow.com/questions/7216543/does-android-ndk-build-with-gc-se...
Steven.
On Sun, Jan 15, 2012 at 7:30 PM, Steven Murdoch Steven.Murdoch@cl.cam.ac.uk wrote:
On 15 Jan 2012, at 20:47, Nick Mathewson wrote:
Another thing to try: recent gccs and their toolchains have a trick where they can stick every function in its own segment, then tell the linker to dump the unused ones. I believe it's called "gc-segments" or something. I have no idea if it would work with openssl, but it could be worth investigating. I believe there's a ticket for tor to use it by default when possible.
clang does something similar with -O4 (link time optimization). See http://llvm.org/docs/LinkTimeOptimization.html near "In this example, the linker recognizes that foo2() ...." for more details
On 01/16/2012 01:11 AM, Eitan Adler wrote:
clang does something similar with -O4 (link time optimization). See http://llvm.org/docs/LinkTimeOptimization.html near "In this example, the linker recognizes that foo2() ...." for more details
Will check it out. Thx!
On 01/15/2012 07:30 PM, Steven Murdoch wrote:
Although post suggests that the Android NKD may have the relevant options on by default: http://stackoverflow.com/questions/7216543/does-android-ndk-build-with-gc-se...
We are still actually building with our pre-NDK "droid-gcc" approach, which most likely means we are not benefiting from NDK optimizations. We have begun rewriting the build process to be NDK-based, but if it ain't broke... etc.
+n8fr8
On 01/15/2012 03:47 PM, Nick Mathewson wrote:
Some stuff to try: openssl has lots of optional features and ciphers; you could probably disable a lot of them. There are configuration options to do so. If you're not sure what, I could try to take a look at the list some time this week.
That would be very helpful, or at least, if you can point me to a spec that indicates which features of OpenSSL that Tor relies upon I can start there.
linker to dump the unused ones. I believe it's called "gc-segments" or something. I have no idea if it would work with openssl, but it could be worth investigating. I believe there's a ticket for tor to use it by
Yes, will check into this. It seems like Android NDK may do this itself, so this might accelerate our transition to using its arm cross-compiler.
+n8fr8
-
Eitan Adler -
Nathan Freitas -
Nick Mathewson -
Steven Murdoch