Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PS-5610: Fix keyring redo encryption in 32 bit builds (5.7) #3176

Merged
merged 1 commit into from
May 14, 2019

Conversation

dutow
Copy link
Contributor

@dutow dutow commented May 9, 2019

The location of the IV was dependent on a sizeof, resulting in an
incorrect data layout written in 32 bit builds.

@dutow
Copy link
Contributor Author

dutow commented May 9, 2019

@@ -919,7 +919,7 @@ fsp_header_fill_encryption_info(

/* Write master key id. */
mach_write_to_4(ptr, key_version);
ptr += sizeof(ulint);
ptr += 8;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks suspicious. mach_write_to_4 writes four bytes, why the pointer is advanced by 8 and not by 4?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the entire proper fix. I was reviewer for this commit. See

commit f565013
Author: Allen Lai [email protected]
Date: Mon Dec 25 10:30:03 2017 +0800

Bug#22740362 ENCRYPTED INNODB DATA FILES ARE NOT PORTABLE BETWEEN 32-BIT AND 64-BIT

Problem:

Not sure if this can be ported as is. That is V3 format created by Percona Server might be unreadable by Oracle MySQL 5.7.

AFAIR, the fix went only to 8.0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@satya-bodapati This is our own code - RK encryption isn't in upstream. I ended up copying a similar code from upstream (or mariadb?) using this sizeof, and only changed it to a fixed size on another part of the code.

@laurynas-biveinis Because this is only the part that writes it, the part that reads it already uses a fixed number, which is 8. This expression also evaluates to 8 on 64 bit builds, where we had no issues with this encryption mode. So I used 8 to keep the format the same as before.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dutow in which case please don't leave uninitialized bytes, this will cause both Valgrind errors and might leak something what is not supposed to be leaked

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@laurynas-biveinis the buffer is zero initialized in log_file_header_fill_encryption. (it is larger than what this function fills, so this isn't the only 4 unused byte in it)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

The location of the IV was dependent on a sizeof, resulting in an
incorrect data layout written in 32 bit builds.
@dutow
Copy link
Contributor Author

dutow commented May 14, 2019

@dutow dutow merged commit 0796b5d into percona:5.7 May 14, 2019
@dutow dutow deleted the ps-5.7-ps5610 branch May 14, 2019 07:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants