Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.1.4
-
Fix Version/s: 10.1.5
-
Component/s: Encryption, Storage Engine - InnoDB, Storage Engine - XtraDB
-
Labels:
Description
If the server starts on a fresh datadir with
innodb-encrypt-tables innodb-encryption-threads = 4
(only with them on top of defaults),
it goes down with the assertion failure:
Stack trace from 10.1 commit 22a7b4dee0
2015-04-18 04:08:34 7fe59fbfa700 InnoDB: Assertion failure in thread 140624204375808 in file fil0crypt.cc line 988 InnoDB: Failing assertion: new_state->key_version != ENCRYPTION_KEY_VERSION_INVALID InnoDB: We intentionally generate a memory trap. #0 0x00007fe5c8fe8165 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007fe5c8feb3e0 in *__GI_abort () at abort.c:92 #2 0x00007fe5cbf5c59c in fil_crypt_get_key_state (new_state=0x7fe59ebfed90) at 10.1/storage/xtradb/fil/fil0crypt.cc:988 #3 0x00007fe5cbf5e734 in fil_crypt_thread (arg=0x0) at 10.1/storage/xtradb/fil/fil0crypt.cc:2148 #4 0x00007fe5caffcb50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #5 0x00007fe5c909195d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #6 0x0000000000000000 in ?? ()
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
I find it somewhat weird – I mean not technically, but logically – that it only fails with innodb-encryption-threads, but doesn't fail if I only set innodb-encrypt-tables.
But anyway, please at least make the assertion more comprehensive for a user, or somehow else print a clear error message in the log.
Jan Lindström, could you please look at it?
I've fixed the assertion rather simply:
diff --git a/storage/xtradb/handler/ha_innodb.cc b/storage/xtradb/handler/ha_inn
--- a/storage/xtradb/handler/ha_innodb.cc
+++ b/storage/xtradb/handler/ha_innodb.cc
@@ -3633,6 +3633,14 @@ innobase_init(
}
#endif
+ if ((srv_encrypt_tables || srv_encrypt_log)
+ && encryption_key_get_latest_version(FIL_DEFAULT_ENCRYPTION_KEY)
+ == ENCRYPTION_KEY_VERSION_INVALID) {
+ sql_print_error("InnoDB: cannot enable encryption, "
+ "encryption plugin is not available");
+ goto error;
+ }
+
os_innodb_umask = (ulint) my_umask;
/* First calculate the default path for innodb_data_home_dir etc.,
And now I get a crash with --innodb-encryption-threads=4 but without --innodb-encrypt-tables. Assert in buf_page_io_complete(), because the page is corrupted. And the page is considered corrupted in here:
/* declare empty pages non-corrupted */ if (checksum_field1 == 0 && checksum_field2 == 0 && *reinterpret_cast<const ib_uint64_t*>(read_buf + FIL_PAGE_LSN) == 0) { /* make sure that the page is really empty */ for (ulint i = 0; i < UNIV_PAGE_SIZE; i++) { if (read_buf[i] != 0) { return(TRUE); } } return(FALSE); }
Because the page looks like this:
(gdb) p read_buf[0] @ UNIV_PAGE_SIZE $1 = '\000' <repeats 32 times>, "\262\326", '\000' <repeats 16349 times>
Could not easily repeat with above fix. Possible fix candidate anyway:
diff --git a/storage/xtradb/handler/ha_innodb.cc b/storage/xtradb/handler/ha_innodb.cc
index 47659fb..c89e317 100644
--- a/storage/xtradb/handler/ha_innodb.cc
+++ b/storage/xtradb/handler/ha_innodb.cc
@@ -3633,6 +3633,21 @@ innobase_init(
}
#endif
+ if ((srv_encrypt_tables || srv_encrypt_log)
+ && encryption_key_get_latest_version(FIL_DEFAULT_ENCRYPTION_KEY)
+ == ENCRYPTION_KEY_VERSION_INVALID) {
+ sql_print_error("InnoDB: cannot enable encryption, "
+ "encryption plugin is not available");
+ goto error;
+ }
+
+ if (!srv_encrypt_tables && srv_n_fil_crypt_threads) {
+ ib_logf(IB_LOG_LEVEL_INFO, "encryption disabled, "
+ "setting number of encryption threads to 0");
+ srv_n_fil_crypt_threads = 0;
+ }
+
+
Cannot repeat this anymore. May be it as a broken build or some later change fixed it.
This is not a bug, it's intentional. You've requested InnoDB to encrypt the data and didn't load an encryption plugin. InnoDB tries to get an encryption key, fails, and crashes the server (which is a typical InnoDB reaction to errors).
Despite being intentional, I agree that it's not good. I'll try to do something about it.