Welcome! Log In Create A New Profile

Advanced

Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

Posted by Sander Hoentjen 
Hi all,

I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
running haproxy stops accepting new SSL connections. When I restart it
works again for almost(?) exactly 1 hour, then stops.
Any idea what might be causing this, or where I should look

# haproxy -vv
HA-Proxy version 1.8.7 2018/04/07
Copyright 2000-2018 Willy Tarreau <[email protected]>

Build options :
  TARGET  = linux2628
  CPU     = generic
  CC      = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -fno-strict-overflow -Wno-unused-label
  OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with network namespace support.
Built with zlib version : 1.2.3
Running on zlib version : 1.2.3
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 7.8 2008-09-05
Running on PCRE version : 7.8 2008-09-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with multi-threading support.
Encrypted password support via crypt(3): yes
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Built with OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
Running on OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3

Available polling systems :
      epoll : pref=300,  test result OK
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
    [TRACE] trace
    [COMP] compression
    [SPOE] spoe

Regards,
Sander Hoentjen
Reading my email again it looks like somehow I messed up part of it,
retrying:

Hi all,

I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
running haproxy stops accepting new SSL connections. When I restart it
works again for almost(?) exactly 1 hour, then stops. Any idea what
might be causing this, or where I should look? Especially the part that
it works for one hour seems weird to me. Next to that, only SSL
connections stop working, the plain ones continue to work. The setup has
one frontend that accepts both http and https, using:
    tcp-request inspect-delay 500ms
    tcp-request content accept if HTTP
    tcp-request content accept if { req.ssl_hello_type 1 }
Maybe this has something to do with it?
Exactly the same config, with only difference being built agains openssl
1.1.0 works without any issues.

Any help appreciated.

Regards,
Sander


On 04/13/2018 10:27 AM, Sander Hoentjen wrote:
> Hi all,
>
> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
> running haproxy stops accepting new SSL connections. When I restart it
> works again for almost(?) exactly 1 hour, then stops.
> Any idea what might be causing this, or where I should look
>
> # haproxy -vv
> HA-Proxy version 1.8.7 2018/04/07
> Copyright 2000-2018 Willy Tarreau <[email protected]>
>
> Build options :
>   TARGET  = linux2628
>   CPU     = generic
>   CC      = gcc
>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -fno-strict-overflow -Wno-unused-label
>   OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
> USE_PCRE=1
>
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with network namespace support.
> Built with zlib version : 1.2.3
> Running on zlib version : 1.2.3
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with PCRE version : 7.8 2008-09-05
> Running on PCRE version : 7.8 2008-09-05
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with multi-threading support.
> Encrypted password support via crypt(3): yes
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Built with OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
> Running on OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
>
> Available polling systems :
>       epoll : pref=300,  test result OK
>        poll : pref=200,  test result OK
>      select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available filters :
>     [TRACE] trace
>     [COMP] compression
>     [SPOE] spoe
>
> Regards,
> Sander Hoentjen
>
Hello Sander,


On 16 April 2018 at 10:55, Sander Hoentjen <[email protected]> wrote:
> Reading my email again it looks like somehow I messed up part of it,
> retrying:
>
> Hi all,
>
> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
> running haproxy stops accepting new SSL connections.

I have seen something like that a few weeks ago as well, but I've
reverted to openssl stable, as I did not have time to get involved
with troubleshooting openssl master at this point.


That having said you may want to retry with latest 1.1.1-pre5, it may
have been already fixed (Prevent a possible recursion in ERR_get_state
....).



Lukas
Hi Lucas,

On 04/17/2018 04:27 PM, Lukas Tribus wrote:
> Hello Sander,
>
>
> On 16 April 2018 at 10:55, Sander Hoentjen <[email protected]> wrote:
>> Reading my email again it looks like somehow I messed up part of it,
>> retrying:
>>
>> Hi all,
>>
>> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
>> running haproxy stops accepting new SSL connections.
> I have seen something like that a few weeks ago as well, but I've
> reverted to openssl stable, as I did not have time to get involved
> with troubleshooting openssl master at this point.
>
>
> That having said you may want to retry with latest 1.1.1-pre5, it may
> have been already fixed (Prevent a possible recursion in ERR_get_state
> ...).
I just tried 1.1.1-pre5, and I still have the same issue. What do you
think, is it better to report to the openssl team, or here? I have no
idea where the issue is coming from, but I was hoping the "broken after
exactly 1 hour" would ring some bells.

Sander
Hello,


On 19 April 2018 at 11:09, Sander Hoentjen <[email protected]> wrote:
> I just tried 1.1.1-pre5, and I still have the same issue.

I'm running 1.1.1-pre6 now with good results. You may want to check that out.


cheers,
lukas
On 05/19/2018 04:55 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 19 April 2018 at 11:09, Sander Hoentjen <[email protected]> wrote:
>> I just tried 1.1.1-pre5, and I still have the same issue.
> I'm running 1.1.1-pre6 now with good results. You may want to check that out.
I did, but I still experience the same issues. What is your exact
haproxy version you tested with? Mine is 1.8.8
Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018

--
Sander
Hello,

On 22 May 2018 at 11:48, Sander Hoentjen <[email protected]> wrote:
> I did, but I still experience the same issues. What is your exact
> haproxy version you tested with? Mine is 1.8.8
> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018

I'm using the development tree. So if it doesn't depend on openssl, it
may be bug that has been fixed in haproxy itself.

Can you try 1.8.9?


Lukas
On 05/22/2018 12:04 PM, Lukas Tribus wrote:
> Hello,
>
> On 22 May 2018 at 11:48, Sander Hoentjen <[email protected]> wrote:
>> I did, but I still experience the same issues. What is your exact
>> haproxy version you tested with? Mine is 1.8.8
>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> I'm using the development tree. So if it doesn't depend on openssl, it
> may be bug that has been fixed in haproxy itself.
>
> Can you try 1.8.9?
I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
issue unfortunately.
Hi Sander,

On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>> Hello,
>>
>> On 22 May 2018 at 11:48, Sander Hoentjen <[email protected]> wrote:
>>> I did, but I still experience the same issues. What is your exact
>>> haproxy version you tested with? Mine is 1.8.8
>>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>> I'm using the development tree. So if it doesn't depend on openssl, it
>> may be bug that has been fixed in haproxy itself.
>>
>> Can you try 1.8.9?
> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
> issue unfortunately.
>

Do you use chroot ?

I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time (or a number of new sess) openssl
try to re-open some /dev/Xrandom sources. And it could fail in a chroot.

https://github.com/openssl/openssl/issues/5330


Emeric
On 05/22/2018 04:19 PM, Emeric Brun wrote:
> Hi Sander,
>
> On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
>> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>>> Hello,
>>>
>>> On 22 May 2018 at 11:48, Sander Hoentjen <[email protected]> wrote:
>>>> I did, but I still experience the same issues. What is your exact
>>>> haproxy version you tested with? Mine is 1.8.8
>>>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>> I'm using the development tree. So if it doesn't depend on openssl, it
>>> may be bug that has been fixed in haproxy itself.
>>>
>>> Can you try 1.8.9?
>> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
>> issue unfortunately.
>>
> Do you use chroot ?
>
> I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time (or a number of new sess) openssl
> try to re-open some /dev/Xrandom sources. And it could fail in a chroot.
>
> https://github.com/openssl/openssl/issues/5330
>
>
Thanks, I do use chroot. In that issue it is mentioned that this problem
has been fixed, but I will test without chroot anyway. Will report
tomorrow if this worked or not.
On 05/22/2018 04:31 PM, Sander Hoentjen wrote:
> On 05/22/2018 04:19 PM, Emeric Brun wrote:
>> Hi Sander,
>>
>> On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
>>> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>>>> Hello,
>>>>
>>>> On 22 May 2018 at 11:48, Sander Hoentjen <[email protected]> wrote:
>>>>> I did, but I still experience the same issues. What is your exact
>>>>> haproxy version you tested with? Mine is 1.8.8
>>>>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>>>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>>> I'm using the development tree. So if it doesn't depend on openssl, it
>>>> may be bug that has been fixed in haproxy itself.
>>>>
>>>> Can you try 1.8.9?
>>> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
>>> issue unfortunately.
>>>
>> Do you use chroot ?
>>
>> I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time (or a number of new sess) openssl
>> try to re-open some /dev/Xrandom sources. And it could fail in a chroot.
>>
>> https://github.com/openssl/openssl/issues/5330
>>
>>
> Thanks, I do use chroot. In that issue it is mentioned that this problem
> has been fixed, but I will test without chroot anyway. Will report
> tomorrow if this worked or not.
I can confirm the issue is gone when I don't use chroot. I will try to
see if I can get more info like a strace soon. I won't be able to today
though. Thanks Lucas and Emeric!
Hello,

On 23 May 2018 at 13:10, Sander Hoentjen <[email protected]> wrote:
> I can confirm the issue is gone when I don't use chroot. I will try to
> see if I can get more info like a strace soon. I won't be able to today
> though. Thanks Lucas and Emeric!

1.8.9 with 1.1.1-pre6 chrooted is now running for me for more than 22
hours. I don't see the same issue.

So are probably we are facing a different issue.



Lukas
Hi Sander, Lukas,

On 05/23/2018 02:32 PM, Lukas Tribus wrote:
> Hello,
>
> On 23 May 2018 at 13:10, Sander Hoentjen <[email protected]> wrote:
>> I can confirm the issue is gone when I don't use chroot. I will try to
>> see if I can get more info like a strace soon. I won't be able to today
>> though. Thanks Lucas and Emeric!
>
> 1.8.9 with 1.1.1-pre6 chrooted is now running for me for more than 22
> hours. I don't see the same issue.
>
> So are probably we are facing a different issue.
>
>
>
> Lukas
>

This issue was due to openssl-1.1.1 which re-seed after an elapsed time or number of request.

If /dev/urandom is used as seeding source when haproxy is chrooted it fails to re-open /dev/urandom ....

By defaut the openssl-1.1.1 configure script uses the syscall getrandom as seeding source and fallback on /dev/urandom if not available.

So you don't face the issue if your openssl-1.1.1 is compiled to use getrandom

But getrandom syscall is available only since kernel > 3.17 and the main point: for glibc > 2.25.

With openssl-1.1.1 you can check this this way:
# ./openssl-1.1.1/openssl version -r
Seeding source: getrandom-syscall


R,
Emeric
Hello,


On 23 May 2018 at 18:29, Emeric Brun <[email protected]> wrote:
> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or number of request.
>
> If /dev/urandom is used as seeding source when haproxy is chrooted it fails to re-open /dev/urandom ....
>
> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as seeding source and fallback on /dev/urandom if not available.
>
> So you don't face the issue if your openssl-1.1.1 is compiled to use getrandom
>
> But getrandom syscall is available only since kernel > 3.17 and the main point: for glibc > 2.25.
>
> With openssl-1.1.1 you can check this this way:
> # ./openssl-1.1.1/openssl version -r
> Seeding source: getrandom-syscall

I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
if kernel headers are installed while compiling, yet -pre6 does not
hang for me in chroot (-pre4 did):

[email protected]:~/libsslbuild/bin$ uname -r
4.4.0-109-generic
[email protected]:~/libsslbuild/bin$ ./openssl version
OpenSSL 1.1.1-pre6 (beta) 1 May 2018
[email protected]:~/libsslbuild/bin$ ./openssl version -r
Seeding source: os-specific
[email protected]:~/libsslbuild/bin$


But, stracing haproxy shows that the library IS ACTUALLY using
getrandom(). So the "Seeding source" output of the executable is
wrong. Gonna dig into this as well, but seeing how my haproxy
executable uses getrandom() calls, this perfectly explains why I did
not see this in -pre6 (which has the build-workaround for < libc 2.25,
while pre4 did not, so it did not use the getrandom() call).


@Sander it looks like openssl folks won't change their mind about
this. You have to either upgrade to a kernel more recent than 3.17 so
that getrandom() can be used, or make /dev/xrandom available within
your chroot.



Lukas
Or kludge around it with eg; http://www.issihosts.com/haveged/ ?

On Wed, May 23, 2018 at 1:48 PM, Lukas Tribus <[email protected]> wrote:

> Hello,
>
>
> On 23 May 2018 at 18:29, Emeric Brun <[email protected]> wrote:
> > This issue was due to openssl-1.1.1 which re-seed after an elapsed time
> or number of request.
> >
> > If /dev/urandom is used as seeding source when haproxy is chrooted it
> fails to re-open /dev/urandom ....
> >
> > By defaut the openssl-1.1.1 configure script uses the syscall getrandom
> as seeding source and fallback on /dev/urandom if not available.
> >
> > So you don't face the issue if your openssl-1.1.1 is compiled to use
> getrandom
> >
> > But getrandom syscall is available only since kernel > 3.17 and the main
> point: for glibc > 2.25.
> >
> > With openssl-1.1.1 you can check this this way:
> > # ./openssl-1.1.1/openssl version -r
> > Seeding source: getrandom-syscall
>
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
>
> [email protected]:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> [email protected]:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> [email protected]:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> [email protected]:~/libsslbuild/bin$
>
>
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).
>
>
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
>
>
>
> Lukas
>
>
Hello,


On 23 May 2018 at 22:17, Jim Freeman <[email protected]> wrote:
> Or kludge around it with eg; http://www.issihosts.com/haveged/ ?

No, it's not about insufficient entropy in the kernel. It's about
interfacing with that entropy while in chroot.


Lukas
On 05/23/2018 09:48 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 23 May 2018 at 18:29, Emeric Brun <[email protected]> wrote:
>> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or number of request.
>>
>> If /dev/urandom is used as seeding source when haproxy is chrooted it fails to re-open /dev/urandom ....
>>
>> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as seeding source and fallback on /dev/urandom if not available.
>>
>> So you don't face the issue if your openssl-1.1.1 is compiled to use getrandom
>>
>> But getrandom syscall is available only since kernel > 3.17 and the main point: for glibc > 2.25.
>>
>> With openssl-1.1.1 you can check this this way:
>> # ./openssl-1.1.1/openssl version -r
>> Seeding source: getrandom-syscall
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
>
> [email protected]:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> [email protected]:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> [email protected]:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> [email protected]:~/libsslbuild/bin$
>
>
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).
>
>
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
When I make /dev/*random available in the chroot, indeed it works fine.
Thanks guys!
As you all have guessed, I am indeed running an older kernel that
doesn't have the getrandom syscall.

Regards,
Sander
Hi Lukas,

On 05/23/2018 09:48 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 23 May 2018 at 18:29, Emeric Brun <[email protected]> wrote:
>> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or number of request.
>>
>> If /dev/urandom is used as seeding source when haproxy is chrooted it fails to re-open /dev/urandom ....
>>
>> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as seeding source and fallback on /dev/urandom if not available.
>>
>> So you don't face the issue if your openssl-1.1.1 is compiled to use getrandom
>>
>> But getrandom syscall is available only since kernel > 3.17 and the main point: for glibc > 2.25.
>>
>> With openssl-1.1.1 you can check this this way:
>> # ./openssl-1.1.1/openssl version -r
>> Seeding source: getrandom-syscall
>
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
>
> [email protected]:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> [email protected]:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> [email protected]:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> [email protected]:~/libsslbuild/bin$
>
>
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).

in pre6 there is a news wrapping function on getrandom which have different fallback way to use the syscall.

Perhaps the openssl -r output depends of that (if getrandom was found from glibc or if a syscall loaded from a different way and considered os-specific).

@Lukas Which build-workarround did you use?

In my case i've patched openssl to define SYS_getrandom (depending of the arch) and i set --with-rand-seed=getrandom

You may have a more elegant way to do that without a patch.

/*
* syscall_random(): Try to get random data using a system call
* returns the number of bytes returned in buf, or <= 0 on error.
*/
int syscall_random(void *buf, size_t buflen)
{
# if defined(OPENSSL_HAVE_GETRANDOM)
return (int)getrandom(buf, buflen, 0);
# endif

# if defined(__linux) && defined(SYS_getrandom)
return (int)syscall(SYS_getrandom, buf, buflen, 0);
# endif

# if defined(__FreeBSD__) && defined(KERN_ARND)
return (int)sysctl_random(buf, buflen);
# endif

/* Supported since OpenBSD 5.6 */
# if defined(__OpenBSD__) && OpenBSD >= 201411
return getentropy(buf, buflen);
# endif

return -1;
}

My patch:
--- openssl-1.1.1-pre6/crypto/rand/rand_unix.c.ori 2018-05-22 14:06:03.490771549 +0200
+++ openssl-1.1.1-pre6/crypto/rand/rand_unix.c 2018-05-22 14:14:33.133237079 +0200
@@ -173,6 +173,26 @@
# define OPENSSL_HAVE_GETRANDOM
# endif

+# if defined(__linux)
+# include <sys/syscall.h>
+#if !defined(SYS_getrandom)
+#if !defined(__NR_getrandom)
+#if defined(__powerpc__) || defined(__powerpc64__)
+#define __NR_getrandom 236
+#elif defined(__sparc__) || defined(__sparc64__)
+#define __NR_getrandom 347
+#elif defined(__x86_64__)
+#define __NR_getrandom 318
+#elif defined (__i386__)
+#define __NR_getrandom 355
+#elif defined (__s390__) || defined(__s390x__)
+#define __NR_getrandom 249
+#endif /* $arch */
+#endif /* __NR_getrandom */
+# define SYS_getrandom __NR_getrandom
+#endif
+#endif
+
# if defined(OPENSSL_HAVE_GETRANDOM)
# include <sys/random.h>
# endif
~


>
>
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
>
>
>
> Lukas
>

Emeric
Hi Emeric,


On 24 May 2018 at 11:19, Emeric Brun <[email protected]> wrote:
> in pre6 there is a news wrapping function on getrandom which have different fallback way to use the syscall.
>
> Perhaps the openssl -r output depends of that (if getrandom was found from glibc or if a syscall loaded from a different way and considered os-specific).

No, openssl version -r output is a verbatim copy of what was passed to
--with-rand-seed at configure time:
https://github.com/openssl/openssl/pull/5910#issuecomment-391514494


> @Lukas Which build-workarround did you use?

No workaround at all, getrandom works for me out of the box in -pre6
(with libc2.23) and the output of "openssl version -r" is
"os-specific", which also is expected behavior as per the github
discussion above. The raw syscall as implemented in-pre6 works for me.


Lukas
Hi Lukas,

On 05/24/2018 11:27 AM, Lukas Tribus wrote:
> Hi Emeric,
>
>
> On 24 May 2018 at 11:19, Emeric Brun <[email protected]> wrote:
>> in pre6 there is a news wrapping function on getrandom which have different fallback way to use the syscall.
>>
>> Perhaps the openssl -r output depends of that (if getrandom was found from glibc or if a syscall loaded from a different way and considered os-specific).
>
> No, openssl version -r output is a verbatim copy of what was passed to
> --with-rand-seed at configure time:
> https://github.com/openssl/openssl/pull/5910#issuecomment-391514494
>
>
>> @Lukas Which build-workarround did you use?
>
> No workaround at all, getrandom works for me out of the box in -pre6
> (with libc2.23) and the output of "openssl version -r" is
> "os-specific", which also is expected behavior as per the github
> discussion above. The raw syscall as implemented in-pre6 works for me.

Ok, i've initialy patched the pre3, and port my patch on pre6 in a different way but i didn't check if it work of the box in pre6 :)

In my case i'm using cross-compilation and there is not access to kernel includes, only those of the builded libc of the sysroot.

This way i don't now how openssl building will be able to retrieve the SYS_getrandom not the syscall def because the are not present in my sysroot.

Anyway, it seems that there was two issues in that thread, do still have one Lukas?


R,
Emeric
On Wed, Jun 27, 2018 at 01:44:08AM +0200, Lukas Tribus wrote:
> Hey guys,
>
>
> FYI after lots of discussions with openssl folks:
>
> https://github.com/openssl/openssl/issues/5330
> https://github.com/openssl/openssl/pull/6388
> https://github.com/openssl/openssl/pull/6432
>
>
> OpenSSL 1.1.1 will now keep the FD open by default:
>
> https://github.com/openssl/openssl/commit/c7504aeb640a88949dfe3146f7e0f275f517464c

Wow good job Lukas! At least now we know that openssl 1.1.1 is not broken
anymore! Thanks for taking care of explaining all these valid use cases
there!

Willy
Hi Lukas,

On 06/27/2018 04:48 AM, Willy Tarreau wrote:
> On Wed, Jun 27, 2018 at 01:44:08AM +0200, Lukas Tribus wrote:
>> Hey guys,
>>
>>
>> FYI after lots of discussions with openssl folks:
>>
>> https://github.com/openssl/openssl/issues/5330
>> https://github.com/openssl/openssl/pull/6388
>> https://github.com/openssl/openssl/pull/6432
>>
>>
>> OpenSSL 1.1.1 will now keep the FD open by default:
>>
>> https://github.com/openssl/openssl/commit/c7504aeb640a88949dfe3146f7e0f275f517464c
>
> Wow good job Lukas! At least now we know that openssl 1.1.1 is not broken
> anymore! Thanks for taking care of explaining all these valid use cases
> there!
>
> Willy
>

I've noticed that. Thank you for your support reporting this issue to openssl's team

R,
Emeric
Sorry, only registered users may post in this forum.

Click here to login