Re: Thread-safe libcrypto by using weak symbols to pthread
On Sun, Mar 29, 2015 at 4:51 AM, Carlos MartÃn Nieto c...@dwim.me wrote: On Sat, Mar 28, 2015 at 09:59:57PM -0700, Philip Guenther wrote: On Sat, 28 Mar 2015, Carlos Mart?n Nieto wrote: I?ve been looking into making libcrypto automatically thread-safe. The obvious solution is to use pthread to perform the locking instead of relying on the user to set locking callbacks, as the final user shouldn?t need to care that LibreSSL is involved in the dependencies at some level. Well. How far is our reach on this? Solving this just for LibreSSL on OpenBSD? I guess you diff works, though it doesn't work when libpthread can be loaded after startup as the bindings won't be updated. If the goal is just this, then application writers in the wider software ecosystem won't even notice and will have to continue to use the callbacks, etc. Fixing this in LibreSSL (even if on all supported OSs) rather than in OpenSSL certainly gives this less reach, but as LibreSSL is a lot more focused on what it wants to support, it makes the implementation for this much less problematic. Today in LibreSSL portable, we already either link -lpthread, or the target OS has some sort of mutex support already factored into the C library directly. I'd be in favor of just always having the mutexes enabled. We're already unconditionally enabling mutexes in arc4random - this is not much of a stretch. I think it makes sense to make some parts of libtls independently threadsafe too, such as tls_init.
Re: Thread-safe libcrypto by using weak symbols to pthread
On Sat, 28 Mar 2015, Carlos Mart?n Nieto wrote: I?ve been looking into making libcrypto automatically thread-safe. The obvious solution is to use pthread to perform the locking instead of relying on the user to set locking callbacks, as the final user shouldn?t need to care that LibreSSL is involved in the dependencies at some level. Well. How far is our reach on this? Solving this just for LibreSSL on OpenBSD? I guess you diff works, though it doesn't work when libpthread can be loaded after startup as the bindings won't be updated. If the goal is just this, then application writers in the wider software ecosystem won't even notice and will have to continue to use the callbacks, etc. Solving this LibreSSL on all ported to platforms? Much harder: have to solve the late-loaded libpthread problem immediately, figure out what works elsewhere, etc. This goal might at least start to make a dent in developer conciousness, but unless/until OpenSSL does something similar developers will still be doing the work. LibreSSL doesn't own the API presented by libcrypto and libssl; we aren't the 600lb gorilla there. (So why haven't they solved it? Just an overriding desire to reduce unnecessary overhead? They have enough compile-time options, so platforms without threads won't have stopped them...) Maybe where we should fix this is libtls, which we *do* control: have libtls do the necessary callbacks... Philip
