FSCRYPT Inline Encryption Ready To Offer Better Performance On Modern SoCs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • elatllat
    replied
    Originally posted by ebiggers View Post

    No. dm-crypt doesn't support inline encryption yet...
    There was some talk about it 2 years ago;



    I guess other Hardware acceleration made it not worth anyone's time.

    Leave a comment:


  • ebiggers
    replied
    Originally posted by elatllat View Post
    So I assume this is just helping per file crypto achieve the speed that per device crypto (cryptsetup) already takes advantage of;
    No. dm-crypt doesn't support inline encryption yet. It can use any encryption implementation that's exposed through Linux's crypto API, but it can't use inline encryption hardware as that follows a different model.

    However, now that Linux's block layer supports inline encryption, it would be straightforward to make dm-crypt support it too, if someone were to have a use case for it.

    Leave a comment:


  • elatllat
    replied
    So I assume this is just helping per file crypto achieve the speed that per device crypto (cryptsetup) already takes advantage of;



    (NotMine999 may be interested in those speeds)
    Last edited by elatllat; 04 August 2020, 09:11 AM.

    Leave a comment:


  • pal666
    replied
    Originally posted by NotMine999 View Post
    "This model allows taking advantage of the inline encryption hardware that is integrated into the UFS or eMMC host controllers on most mobile SoCs."

    So no indication of what platforms or SoC were tested, if any.

    No documentation or test plan or test results.

    Basically No Proof to back up the claim in the GIT PULL.
    you have reading comprehension issues. "this model allows taking advantage" can be proved by reading sources. whether it will increase speed on real(including future) hardware - depends on many factors, but without this model you can't even benchmark it

    Leave a comment:


  • ebiggers
    replied
    Originally posted by numacross View Post
    You're correct in that the possibility of disabling encryption for a given block to read it back and check makes this more reliable than self-encrypting drives of the past.
    Yep, that's what is being done, both in xfstests for upstream, and in VtsKernelEncryptionTest for Android. The same tests have to pass regardless of whether inline encryption is being used or not.

    Leave a comment:


  • numacross
    replied
    Originally posted by ebiggers View Post

    Inline encryption is different from self-encrypting drives because the encrypted data is the same regardless of whether you're using inline encryption or not. So inline encryption is just another encryption implementation, which is being tested just like any other implementation.

    This is very different from self-encrypting drives where the end result is undefined and isn't even exposed to software, and thus can't be tested.
    You have no guarantees for when a hardware inline encryption keyslot is configured with AES and a given key that it will actually use AES to store the data at rest - it might perform ROT(13+key) for example. You can't really test that either without physically reading the storage device directly and comparing outputs. This is no different than the flaw of BitLocker relying on hardware for encryption.

    Edit: After reading more deeply about this I'm retracting my opinion above. You're correct in that the possibility of disabling encryption for a given block to read it back and check makes this more reliable than self-encrypting drives of the past.
    Last edited by numacross; 03 August 2020, 05:00 PM.

    Leave a comment:


  • ebiggers
    replied
    Or they will learn the hard way just like Microsoft did with trusting SSD makers in the past.
    Inline encryption is different from self-encrypting drives because the encrypted data is the same regardless of whether you're using inline encryption or not. So inline encryption is just another encryption implementation, which is being tested just like any other implementation.

    This is very different from self-encrypting drives where the end result is undefined and isn't even exposed to software, and thus can't be tested.

    Leave a comment:


  • ebiggers
    replied
    Originally posted by NotMine999 View Post
    So no indication of what platforms or SoC were tested, if any.

    No documentation or test plan or test results.

    Basically No Proof to back up the claim in the GIT PULL.

    I guess the important stuff, like proving one's code performs as well as it's claimed to perform, is buried in yet another email thread or mailing list that has no citation.

    Or perhaps the information I seek is buried in the source code? I somehow doubt that, based on the summary of files changed as listed in the GIT PULL.
    Did you read the last paragraph of the pull request description, which summarizes how it was tested?

    Also, the pull request description is just a brief summary. If you want to know more you need to read the commit messages, documentation, etc. Note also, this pull request was just the filesystem-level part and is hardware-agnostic. The block and driver changes have gone in through different trees.

    Leave a comment:


  • numacross
    replied
    Originally posted by NotMine999 View Post
    Quoting from the GIT PULL (link is cited in the original article):

    "This model allows taking advantage of the inline encryption hardware that is integrated into the UFS or eMMC host controllers on most mobile SoCs."

    So no indication of what platforms or SoC were tested, if any.

    No documentation or test plan or test results.

    Basically No Proof to back up the claim in the GIT PULL.

    I guess the important stuff, like proving one's code performs as well as it's claimed to perform, is buried in yet another email thread or mailing list that has no citation.

    Or perhaps the information I seek is buried in the source code? I somehow doubt that, based on the summary of files changed as listed in the GIT PULL.
    Or they will learn the hard way just like Microsoft did with trusting SSD makers in the past.

    Leave a comment:


  • NotMine999
    replied
    Another interesting improvement to Linux, if it's true, can be proven, can be repeated across multiple platforms using different chips with the same supporting feature(s).

    Quoting from the GIT PULL (link is cited in the original article):

    "This model allows taking advantage of the inline encryption hardware that is integrated into the UFS or eMMC host controllers on most mobile SoCs."

    So no indication of what platforms or SoC were tested, if any.

    No documentation or test plan or test results.

    Basically No Proof to back up the claim in the GIT PULL.

    I guess the important stuff, like proving one's code performs as well as it's claimed to perform, is buried in yet another email thread or mailing list that has no citation.

    Or perhaps the information I seek is buried in the source code? I somehow doubt that, based on the summary of files changed as listed in the GIT PULL.

    Leave a comment:

Working...
X