MDEV-34372 Temporary tablespace decryption fails with ER_NOT_KEYFILE

[Thirunarayanan]

• The Jira issue number for this PR is: MDEV-34372

Description

Reason:

Temporary tablespace uses the innodb redo encryption key and key
version(v1) to encrypt the temporary tablespace/files. When encryption key rotation happens, InnoDB assigns the new redo encryption key version(v2) during checkpoint. After this, InnoDB encrypts the temporary tablespace pages using key version (v2). This lead to failure of decrypting the temporary tablespace pages which was encrypted using key version (v1).

Fix:

Store the temporary file/tablespace key and key version
seperately during redo log initialization. Even though InnoDB does key rotation, it doesn't affect temporary file key and key version.

log_crypt_init(): Assign the temporary file/tablespace key and key version

i_s_dict_fill_temp_tablespaces_encryption(): Adds the temporary tablespace information if
innodb_encrypt_temporary_tables is enabled

How can this PR be tested?

./mtr encryption.redo_key_rotation --mem

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the latest MariaDB development branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[dr-m]

Is there any way to reduce the risk of leaking the encryption key? As far as I understand, here we would copy the key even if key rotation is not supported.

Could we fetch the old key version on demand? Can we store the used key version somewhere within the encrypted block? If not, could we at least perform some additional steps to ensure that the tmp_crypt_key will not be written to a swap file (mlock) or core dump files (madvise)?

Based on the description, there might also be a problem with persistent encrypted tables when the key is rotated and a previously evicted page needs to be read in. How would this case work?