httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Fixing more OpenSSL callback crashes
Date Wed, 12 Apr 2017 14:53:43 GMT
Hi Jacob,

Am 12.04.2017 um 02:16 schrieb Jacob Champion:
> On 04/10/2017 03:59 PM, Jacob Champion wrote:
>> So it looks like my test program might still be a possible solution for
>> detecting whether we need a callback at configure time, unless anyone
>> knows of a platform where two thread-local errnos can have the same
>> address some of the time and different addresses at other times...
>
> I've checked my first attempt into trunk. It writes the result into the
> new AP_OPENSSL_USE_ERRNO_THREADID macro in ap_config_auto.h. On
> platforms where every thread has its own errno address, that macro will
> be #defined to 1.
>
> Rainer, would you mind sanity-checking the result on your Solaris box
> (sounds like the test should *not* pass there)? I've tested on Ubuntu
> 16.04, where the test passes.

The good news:

I checked by compiling your test program standalone (outside of 
configure) to be able to run it easily very often (1000 times). I 
checked on Solaris 8 (32 Bit) and 10 Sparc (32 Bit and 64 Bit) compilation.

When I compile without any flags, the test fails with return code 5, 
when I compile with -D_REENTRANT it succeeds (rc 0). Since apr always 
adds -D_REENTRANT for Solaris in build/apr_hints.m4 (independent of 
APR_HAS_THREADS), and your test runs in httpd configure after apr 
configure and thus inherits the flags, the test would correctly detect a 
thread-safe errno for Solaris during configure.

The bad news:

If building httpd with apr/apu sources in srclib and using 
--with-included-apr (and not assuming some unrelated installed system 
APR), the test can't run, because the binary needs to get linked against 
libapr-1 during configure runtime (where the lib has not yet been 
build). I don't know how easy a non-apr using test would be that still 
runs on the relevant target platforms :(

Side note:

I did increase NUM_THREADS to 10. But actually your original number of 3 
gave the same results. Nevertheless I would increase the number if it is 
OK for you (I know, quadratic behavior, but we shouldn't care too much 
for this test):

Index: trunk/acinclude.m4
===================================================================
--- trunk/acinclude.m4    (revision 1791085)
+++ trunk/acinclude.m4    (working copy)
@@ -653,7 +653,7 @@
            #include "apr_thread_cond.h"
            #include "apr_thread_proc.h"

-          #define NUM_THREADS 3
+          #define NUM_THREADS 10

            struct thread_data {
                apr_thread_mutex_t *mutex;
@@ -692,6 +692,7 @@
            int ret = 0;
            apr_status_t status;
            int i;
+          int j;

            apr_pool_t         *pool;
            apr_thread_mutex_t *mutex;
@@ -738,10 +739,13 @@
            }

            /* Check that no addresses were duplicated. */
-          if ((tdata[0].errno_addr == tdata[1].errno_addr)
-              || (tdata[1].errno_addr == tdata[2].errno_addr)
-              || (tdata[0].errno_addr == tdata[2].errno_addr)) {
-              ret = 5;
+          for (i = 0; i < NUM_THREADS - 1; ++i) {
+              for (j = i + 1; j < NUM_THREADS; ++j) {
+                  if (tdata[i].errno_addr == tdata[j].errno_addr) {
+                      ret = 5;
+                      goto out;
+                  }
+              }
            }

        out:


> If there's anyone else who wouldn't mind updating and posting their
> platform and test result, that would really help me figure out how
> widespread the "problem" is. Remember to rebuild configure first! :)

Regards,

Rainer

Mime
View raw message