Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-15406

Using the native fscrypt for Ubuntu20 5.4 kernel fails several migration test

Details

    • Bug
    • Resolution: Fixed
    • Critical
    • Lustre 2.15.0
    • Lustre 2.15.0
    • None
    • Ubuntu20 client running 5.4 kernel.
    • 3
    • 9223372036854775807

    Description

      To validate the port of fscrypt for RHEL8 which is from a 5.4 kernel I changed the build system to automatically use the native fscrypt for the Ubuntu 5.4 kernel. In theory it should have identical results. This is not the case which you can see the test failures with patch https://review.whamcloud.com/#/c/45907.

      Attachments

        Issue Links

          Activity

            [LU-15406] Using the native fscrypt for Ubuntu20 5.4 kernel fails several migration test
            pjones Peter Jones added a comment -

            Landed for 2.15

            pjones Peter Jones added a comment - Landed for 2.15

            "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/45987/
            Subject: LU-15406 sec: fix in-kernel fscrypt support
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: 2169aed82a32df47be9aef2f249178ede6c7fadd

            gerrit Gerrit Updater added a comment - "Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/45987/ Subject: LU-15406 sec: fix in-kernel fscrypt support Project: fs/lustre-release Branch: master Current Patch Set: Commit: 2169aed82a32df47be9aef2f249178ede6c7fadd

            Thank you. I will test.

            simmonsja James A Simmons added a comment - Thank you. I will test.
            sebastien Sebastien Buisson added a comment - - edited

            This problem seen with the in-kernel fscrypt library is limited to file migration (sanity-sec test_52 and test_59b). In this use case, Lustre creates a temporary, volatile file to migrate data. For encrypted files, we explicitly set the encryption context of the volatile file (directly on server side) to be the same as the original file, so that data is encrypted with the same key. Problem is the encryption context of the original file is simply not retrieved when using the in-kernel fscrypt lib. So the volatile file has its own encryption context, which makes the migrated content encrypted with a different key. And this key is trashed. As a consequence, the content of the file after migration cannot just be decrypted properly.

            I have pushed https://review.whamcloud.com/45987 to fix this issue.

            sebastien Sebastien Buisson added a comment - - edited This problem seen with the in-kernel fscrypt library is limited to file migration (sanity-sec test_52 and test_59b). In this use case, Lustre creates a temporary, volatile file to migrate data. For encrypted files, we explicitly set the encryption context of the volatile file (directly on server side) to be the same as the original file, so that data is encrypted with the same key. Problem is the encryption context of the original file is simply not retrieved when using the in-kernel fscrypt lib. So the volatile file has its own encryption context, which makes the migrated content encrypted with a different key. And this key is trashed. As a consequence, the content of the file after migration cannot just be decrypted properly. I have pushed https://review.whamcloud.com/45987 to fix this issue.

            "Sebastien Buisson <sbuisson@ddn.com>" uploaded a new patch: https://review.whamcloud.com/45987
            Subject: LU-15406 sec: fix in-kernel fscrypt support
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 6eda4575b6f9bf678c2036d25d500f9e3d9ec335

            gerrit Gerrit Updater added a comment - "Sebastien Buisson <sbuisson@ddn.com>" uploaded a new patch: https://review.whamcloud.com/45987 Subject: LU-15406 sec: fix in-kernel fscrypt support Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 6eda4575b6f9bf678c2036d25d500f9e3d9ec335
            pjones Peter Jones added a comment -

            Seb

            Could you please investigate?

            Thanks

            Peter

            pjones Peter Jones added a comment - Seb Could you please investigate? Thanks Peter

            People

              sebastien Sebastien Buisson
              simmonsja James A Simmons
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: