Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1, 10.2
-
FIPS, RHEL-7.4
-
10.1.31
Description
This is the same issue as MDEV-14064, but since I couldn't re-open the closed one, opening a new. The issue MDEV-14064 was closed as it seemed to be problem in openssl library, but in the end there is issue in MariaDB 10.1 as well (see bellow).
It looks like it works fine with older openssl:
openssl-libs-1.0.1e-60.el7_3.1
but it starts to fail with RHEL-7.4 openssl:
openssl-libs-1.0.2k-8.el7
How to reproduce:
#> yum install rh-mariadb101
|
#> rm -rf /var/opt/rh/rh-mariadb101/lib/mysql/*
|
#> scl enable rh-mariadb101 bash
|
#> /opt/rh/rh-mariadb101/root/usr/libexec/mysqld run --lc-messages=en_US --bootstrap --basedir=/opt/rh/rh-mariadb101/root/usr --datadir=/var/opt/rh/rh-mariadb101/lib/mysql --log-warnings=1 --enforce-storage-engine= --user=mysql --max_allowed_packet=8M --net_buffer_length=16K
|
Current results:
mysqld crashes with this back-trace:
#0 0x00007ffff63011f7 in raise () from /lib64/libc.so.6
|
#1 0x00007ffff63028e8 in abort () from /lib64/libc.so.6
|
#2 0x00005555558ee9cf in openssl_lock (line=<optimized out>, file=<optimized out>, lock=<optimized out>, mode=<optimized out>) at /usr/src/debug/mariadb-10.1.26/sql/mysqld.cc:4706
|
#3 openssl_lock_function (mode=<optimized out>, n=18, file=<optimized out>, line=<optimized out>) at /usr/src/debug/mariadb-10.1.26/sql/mysqld.cc:4674
|
#4 0x00007ffff6fc396d in drbg_rand_add (ctx=0x7ffff72fce60 <ossl_dctx>, in=0x7fffffff4e90, inlen=48, entropy=48) at rand_lib.c:240
|
#5 0x00007ffff6fc4469 in RAND_poll () at rand_unix.c:405
|
#6 0x00007ffff6fc3076 in ssleay_rand_bytes (buf=0x55555766a338 "", num=16, pseudo=0, lock=1) at md_rand.c:398
|
#7 0x0000555556003160 in my_random_bytes (buf=0x55555766a338 "", num=16) at /usr/src/debug/mariadb-10.1.26/mysys_ssl/my_crypt.cc:315
|
#8 0x0000555555e8e394 in fil_space_crypt_t (new_encryption=FIL_ENCRYPTION_DEFAULT, new_key_id=1, new_min_key_version=0, new_type=0, this=0x55555766a338)
|
at /usr/src/debug/mariadb-10.1.26/storage/xtradb/include/fil0crypt.h:124
|
#9 fil_space_create_crypt_data (type=0, min_key_version=0, key_id=1, encrypt_mode=FIL_ENCRYPTION_DEFAULT) at /usr/src/debug/mariadb-10.1.26/storage/xtradb/fil/fil0crypt.cc:246
|
#10 fil_space_create_crypt_data (encrypt_mode=encrypt_mode@entry=FIL_ENCRYPTION_DEFAULT, key_id=key_id@entry=1) at /usr/src/debug/mariadb-10.1.26/storage/xtradb/fil/fil0crypt.cc:266
|
#11 0x0000555555db5779 in open_or_create_data_files (create_new_db=create_new_db@entry=0x7fffffff8910, min_arch_log_no=min_arch_log_no@entry=0x7fffffff8930,
|
max_arch_log_no=max_arch_log_no@entry=0x7fffffff8940, flushed_lsn=flushed_lsn@entry=0x7fffffff8920, sum_of_new_sizes=sum_of_new_sizes@entry=0x7fffffff8950)
|
at /usr/src/debug/mariadb-10.1.26/storage/xtradb/srv/srv0start.cc:1233
|
#12 0x0000555555db6da2 in innobase_start_or_create_for_mysql () at /usr/src/debug/mariadb-10.1.26/storage/xtradb/srv/srv0start.cc:2275
|
#13 0x0000555555cd7e2d in innobase_init (p=<optimized out>) at /usr/src/debug/mariadb-10.1.26/storage/xtradb/handler/ha_innodb.cc:4452
|
#14 0x0000555555b14954 in ha_initialize_handlerton (plugin=0x55555710ba18) at /usr/src/debug/mariadb-10.1.26/sql/handler.cc:513
|
#15 0x000055555599d970 in plugin_initialize (tmp_root=tmp_root@entry=0x7fffffffd4f0, plugin=plugin@entry=0x55555710ba18, argc=argc@entry=0x555556841be0 <remaining_argc>, argv=argv@entry=0x5555570bbb28,
|
options_only=options_only@entry=false) at /usr/src/debug/mariadb-10.1.26/sql/sql_plugin.cc:1406
|
#16 0x000055555599f20a in plugin_init (argc=argc@entry=0x555556841be0 <remaining_argc>, argv=0x5555570bbb28, flags=2) at /usr/src/debug/mariadb-10.1.26/sql/sql_plugin.cc:1684
|
#17 0x00005555558f4b08 in init_server_components () at /usr/src/debug/mariadb-10.1.26/sql/mysqld.cc:5154
|
#18 0x00005555558f8470 in mysqld_main (argc=17, argv=0x5555570bbb28) at /usr/src/debug/mariadb-10.1.26/sql/mysqld.cc:5741
|
#19 0x00007ffff62edc05 in __libc_start_main () from /lib64/libc.so.6
|
#20 0x00005555558ec05d in _start ()
|
After talking to openssl developer, it turned out that MariaDB (deliberately) uses internal function RAND_SSLeay(), with this explanation:
int my_random_bytes(uchar *buf, int num)
|
{
|
/*
|
Unfortunately RAND_bytes manual page does not provide any guarantees
|
in relation to blocking behavior. Here we explicitly use SSLeay random
|
instead of whatever random engine is currently set in OpenSSL. That way
|
we are guaranteed to have a non-blocking random.
|
*/
|
if (RAND_bytes(buf, num) != 1)
|
return MY_AES_OPENSSL_ERROR;
|
return MY_AES_OK;
|
}
|
This is what the openssl developer said about the comment above: The assumption is worthless. The RAND_SSLeay RNG can and will call read() on /dev/urandom in the FIPS mode anyway and actually using RAND_bytes() is much less probable to do that in the FIPS mode - it reads from /dev/urandom for reseed only when the automatic reseed interval is passed. The question also is what 'blocking' means here in this context and why it was so crucial for RNG to not block. Read from /dev/urandom is not supposed to block for example. There is no explanation for that.
Well, it looks like something will get fixed on openssl part as well, but I think the mariadb code should only used the documented function.
Attachments
Issue Links
- duplicates
-
-
- Closed
-