Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-15032

Encrypted database created on big endian machine cannot be used on little endian machine

Details

    • 10.2.13

    Description

      See attached test case how to create tables on test and actual used database.

      Attachments

        1. big_endian_notpatched.tgz
          674 kB
          Jan Lindström
        2. big_endian_patched.tgz
          674 kB
          Jan Lindström
        3. little_endian_notpatched.tgz
          677 kB
          Jan Lindström
        4. little_endian_patched.tgz
          677 kB
          Jan Lindström
        5. my.cnf
          0.3 kB
          Jan Lindström

        Issue Links

          Activity

            jplindst Jan Lindström (Inactive) added a comment - https://github.com/MariaDB/server/tree/bb-10.1-MDEV-15032

            The fil_iterate() code had been refactored in MDEV-12396. I ported the patch and did some other cleanup.
            This change alone (verify the encrypted page checksum before decryption in IMPORT) does not appear to fix anything. We additionally have to implement the correct CRC-32C checksum on big endian machines, so that after the fix, big endian machines will create portable data files.

            I would not touch the checksums of little-endian machines, so that the checksums will not become weaker. On big-endian machines, they will necessarily be weakened, because in case the proper CRC-32C checksum produces a mismatch, we would fall back to computing the buggy "legacy CRC-32C" checksum. In MariaDB 10.4, we can remove support for the "legacy CRC-32C". This would affect big-endian machines only.

            marko Marko Mäkelä added a comment - The fil_iterate()  code had been refactored in MDEV-12396 . I ported the patch and did some other cleanup. This change alone (verify the encrypted page checksum before decryption in IMPORT) does not appear to fix anything. We additionally have to implement the correct CRC-32C checksum on big endian machines, so that after the fix, big endian machines will create portable data files. I would not touch the checksums of little-endian machines, so that the checksums will not become weaker. On big-endian machines, they will necessarily be weakened, because in case the proper CRC-32C checksum produces a mismatch, we would fall back to computing the buggy "legacy CRC-32C" checksum. In MariaDB 10.4, we can remove support for the "legacy CRC-32C". This would affect big-endian machines only.

            The submitted MDEV-15032 fix consisted of two commits. The first one backports some changes to ut_crc32(), and the second one modifies IMPORT TABLESPACE so that the encrypted page checksum will be validated before decryption of the page is attempted. I pushed the latter patch as part of the MDEV-16416 bug fix.

            What remains to be done in this ticket is a fix of the CRC-32C checksum in a way that does not weaken the checksum on little-endian systems.

            marko Marko Mäkelä added a comment - The submitted MDEV-15032 fix consisted of two commits. The first one backports some changes to ut_crc32() , and the second one modifies IMPORT TABLESPACE  so that the encrypted page checksum will be validated before decryption of the page is attempted. I pushed the latter patch as part of the MDEV-16416 bug fix. What remains to be done in this ticket is a fix of the CRC-32C checksum in a way that does not weaken the checksum on little-endian systems.

            I don’t think that we should spend effort on this unless someone complains. The CRC-32C implementation that is used by InnoDB encryption is byte order agnostic starting with MariaDB 10.2.2.

            marko Marko Mäkelä added a comment - I don’t think that we should spend effort on this unless someone complains. The CRC-32C implementation that is used by InnoDB encryption is byte order agnostic starting with MariaDB 10.2.2.

            This bug affected the 10.1 series only, and 10.1 has reached its end of life.

            marko Marko Mäkelä added a comment - This bug affected the 10.1 series only, and 10.1 has reached its end of life.

            People

              jplindst Jan Lindström (Inactive)
              jplindst Jan Lindström (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.