[PATCH] openssl: add rdcpu to rand-seed

[PATCH] openssl: add rdcpu to rand-seed

[Taras Kondratiuk]

Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
kernel:
140737348333184:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342

Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
seed source for kernels >=4.8. The assumption is that getrandom(2) will
be used instead. Getrandom syscall was added in kernel 3.17 by commit
c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
devrandom can't be used.

To workaround this issue add 'rdcpu' as additional source of entropy for
the rand seed. Also devrandom in the list is no-op since os = getrandom
+ devrandom on Linux, so remove it. The comment is also not relevant
anymore.

Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 47ed6b7640b3..2bf7f56183ce 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -43,10 +43,8 @@ do_configure[cleandirs] = "${B}"
 EXTRA_OECONF_append_libc-musl = " no-async"
 EXTRA_OECONF_append_libc-musl_powerpc64 = " no-asm"
 
-# adding devrandom prevents openssl from using getrandom() which is not available on older glibc versions
-# (native versions can be built with newer glibc, but then relocated onto a system with older glibc)
-EXTRA_OECONF_class-native = "--with-rand-seed=os,devrandom"
-EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
+EXTRA_OECONF_class-native = "--with-rand-seed=os,rdcpu"
+EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,rdcpu"
 
 # Relying on hardcoded built-in paths causes openssl-native to not be relocateable from sstate.
 CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin -DENGINESDIR=/not/builtin"
-- 
2.25.1

Re: [PATCH] openssl: add rdcpu to rand-seed

[Khem Raj]

On Fri, Jul 10, 2020 at 12:40 PM Taras Kondratiuk <takondra@cisco.com> wrote:
>
> Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> kernel:
> 140737348333184:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
>
> Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> seed source for kernels >=4.8. The assumption is that getrandom(2) will
> be used instead. Getrandom syscall was added in kernel 3.17 by commit
> c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> devrandom can't be used.
>
> To workaround this issue add 'rdcpu' as additional source of entropy for
> the rand seed. Also devrandom in the list is no-op since os = getrandom
> + devrandom on Linux, so remove it. The comment is also not relevant
> anymore.
>

I think rdcpu will work on x86 hosts but not on say aarch64 build
hosts. Can we still
have devrandom as an option if rdcpu fails ?

> Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
> ---
>  meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> index 47ed6b7640b3..2bf7f56183ce 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
> @@ -43,10 +43,8 @@ do_configure[cleandirs] = "${B}"
>  EXTRA_OECONF_append_libc-musl = " no-async"
>  EXTRA_OECONF_append_libc-musl_powerpc64 = " no-asm"
>
> -# adding devrandom prevents openssl from using getrandom() which is not available on older glibc versions
> -# (native versions can be built with newer glibc, but then relocated onto a system with older glibc)
> -EXTRA_OECONF_class-native = "--with-rand-seed=os,devrandom"
> -EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
> +EXTRA_OECONF_class-native = "--with-rand-seed=os,rdcpu"
> +EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,rdcpu"
>
>  # Relying on hardcoded built-in paths causes openssl-native to not be relocateable from sstate.
>  CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin -DENGINESDIR=/not/builtin"
> --
> 2.25.1
>

Re: [PATCH] openssl: add rdcpu to rand-seed

[Taras Kondratiuk]

On Fri, 2020-07-10 at 13:01 -0700, Khem Raj wrote:
> On Fri, Jul 10, 2020 at 12:40 PM Taras Kondratiuk <takondra@cisco.com> wrote:
> > Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> > glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> > kernel:
> > 140737348333184:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> > 
> > Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> > Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> > seed source for kernels >=4.8. The assumption is that getrandom(2) will
> > be used instead. Getrandom syscall was added in kernel 3.17 by commit
> > c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> > system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> > devrandom can't be used.
> > 
> > To workaround this issue add 'rdcpu' as additional source of entropy for
> > the rand seed. Also devrandom in the list is no-op since os = getrandom
> > + devrandom on Linux, so remove it. The comment is also not relevant
> > anymore.
> > 
> 
> I think rdcpu will work on x86 hosts but not on say aarch64 build
> hosts. Can we still
> have devrandom as an option if rdcpu fails ?

Devrandom is part of 'os' already, so devrandom will be still used.
Rdcpu will be tried as a fallback only *after* getrandom and devrandom
failed.

Here in rand_pool_acquire_entropy() the order of sources is getrandom,
devrandom and then rdcpu:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1g/crypto/rand/rand_unix.c#L618

Re: [OE-core] [PATCH] openssl: add rdcpu to rand-seed

[Richard Purdie]

On Fri, 2020-07-10 at 12:39 -0700, Taras Kondratiuk via lists.openembedded.org wrote:
> Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> kernel:
> 140737348333184:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> 
> Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> seed source for kernels >=4.8. The assumption is that getrandom(2) will
> be used instead. Getrandom syscall was added in kernel 3.17 by commit
> c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> devrandom can't be used.

Where would we find a system where we're building with pre-3.17 libc
headers?

We updated to 3.17 in 2014:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=be50d1dc1c03b709e60d2493df5890f7556852b7

If I remember correctly this change was added to avoid problems with
different host OSes and I'm worried we'd see those issues return if we
change things like this. Whilst the syscall may have been added quite
early, the glibc wrappers for it are quite recent and where our source
of problems was.

Khem's concerns about this being x86 only also worry me.

Cheers,

Richard
> 

Re: [OE-core] [PATCH] openssl: add rdcpu to rand-seed

[Adrian Bunk]

On Fri, Jul 10, 2020 at 09:21:26PM +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 12:39 -0700, Taras Kondratiuk via lists.openembedded.org wrote:
> > Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> > glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> > kernel:
> > 140737348333184:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> > 
> > Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> > Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> > seed source for kernels >=4.8. The assumption is that getrandom(2) will
> > be used instead. Getrandom syscall was added in kernel 3.17 by commit
> > c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> > system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> > devrandom can't be used.
> 
> Where would we find a system where we're building with pre-3.17 libc
> headers?
> 
> We updated to 3.17 in 2014:
>...

Native uses the host one.

In Yocto >= 3.1 old host distributions have to use the 
buildtools-extended tarball for unrelated reasons,
which should fix this problem.

Building Yocto <= 3.0 on Debian 8 (3.16 userspace headers) running the 
optional kernel 4.9 would match the reported problem.

Or building Yocto <= 3.0 in a chroot with an older distribution
on a system running a more recent kernel.

> Cheers,
> 
> Richard

cu
Adrian

Re: [OE-core] [PATCH] openssl: add rdcpu to rand-seed

[Taras Kondratiuk]

On Fri, 2020-07-10 at 21:21 +0100, Richard Purdie wrote:
> On Fri, 2020-07-10 at 12:39 -0700, Taras Kondratiuk via lists.openembedded.org wrote:
> > Native[sdk] openssl fails to initialize RNG on systems where native[sdk]
> > glibc is built against pre-3.17 linux-libc-headers, but runs on 4.8+
> > kernel:
> > 140737348333184:error:2406C06E:random number generator:RAND_DRBG_instantiate:error retrieving entropy:../openssl-1.1.1g/crypto/rand/drbg_lib.c:342
> > 
> > Commit 3ff98f558157 ("Start up DEVRANDOM entropy improvement for older
> > Linux devices.") in OpenSSL 1.1.1d has effectively disabled devrandom
> > seed source for kernels >=4.8. The assumption is that getrandom(2) will
> > be used instead. Getrandom syscall was added in kernel 3.17 by commit
> > c6e9d6f38894 ("random: introduce getrandom(2) system call"). So on a
> > system with 4.8+ kernel and pre-3.17 libc headers both getrandom and
> > devrandom can't be used.
> 
> Where would we find a system where we're building with pre-3.17 libc
> headers?
> 
> We updated to 3.17 in 2014:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=be50d1dc1c03b709e60d2493df5890f7556852b7
> 
> If I remember correctly this change was added to avoid problems with
> different host OSes and I'm worried we'd see those issues return if we
> change things like this. Whilst the syscall may have been added quite
> early, the glibc wrappers for it are quite recent and where our source
> of problems was.

We build OE SDK that has to work on build machines with kernels from
2.6.32 to 5.4. So in our distro nativesdk-linux-libc-headers is set to
2.6.32.

If you think this is a rare case and won't be useful for others, then
ignore the patch. I'll override --with-rand-seed from distro layer.

But then we can remove --with-rand-seed configuration from OE-core
recipe entirely. Its current value "os,devrandom" is equivalent to the
default configuration.