FSCRYPT Inline Encryption Ready To Offer Better Performance On Modern SoCs

[phoronix]

Phoronix: FSCRYPT Inline Encryption Ready To Offer Better Performance On Modern SoCs

After being worked on a number of months, the FSCRYPT file-system encryption framework for the Linux kernel is enabling inline encryption support with the 5.9 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=FSCRYPT-Inline-Encrypt-5.9

[tildearrow]

Typo:

Still being addressed is direct I/O on encrypoted files.

[NotMine999]

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.

[numacross]

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.

[ebiggers]

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.

[ebiggers]

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.

[numacross]

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.

[ebiggers]

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.

[pal666]

"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

[elatllat]

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

https://forum.odroid.com/viewtopic.php?f=149&t=30103

(NotMine999 may be interested in those speeds)