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): > > lukas@dev:~/libsslbuild/bin$ uname -r > 4.4.0-109-generic > lukas@dev:~/libsslbuild/bin$ ./openssl version > OpenSSL 1.1.1-pre6 (beta) 1 May 2018 > lukas@dev:~/libsslbuild/bin$ ./openssl version -r > Seeding source: os-specific > lukas@dev:~/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 > >
