| Message ID | 20190815192858.28125-1-ard.biesheuvel@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | crypto: switch to crypto API for ESSIV generation | expand |
Hi Ard, On 15/08/2019 21:28, Ard Biesheuvel wrote: > Changes since v10: > - Drop patches against fscrypt and dm-crypt - these will be routed via the > respective maintainer trees during the next cycle I tested the previous dm-crypt patches (I also try to keep them in my kernel.org tree), it works and looks fine to me (and I like the final cleanup :) Once all maintainers are happy with the current state, I think it should go to the next release (5.4; IMO both ESSIV API and dm-crypt changes). Maybe you could keep sending dm-crypt patches in the end of the series (to help testing it)? (Just for for now I am completely distracted by other urgent unrelated issues.) Milan -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Fri, 16 Aug 2019 at 10:29, Milan Broz <gmazyland@gmail.com> wrote: > > Hi Ard, > > On 15/08/2019 21:28, Ard Biesheuvel wrote: > > Changes since v10: > > - Drop patches against fscrypt and dm-crypt - these will be routed via the > > respective maintainer trees during the next cycle > > I tested the previous dm-crypt patches (I also try to keep them in my kernel.org tree), > it works and looks fine to me (and I like the final cleanup :) > > Once all maintainers are happy with the current state, I think it should go to > the next release (5.4; IMO both ESSIV API and dm-crypt changes). > Maybe you could keep sending dm-crypt patches in the end of the series (to help testing it)? > OK. But we'll need to coordinate a bit so that the first patch (the one that introduces the template) is available in both branches, otherwise ESSIV will be broken in the dm branch until it hits another branch (-next or mainline) that also contains cryptodev. As I suggested before, I can easily create a branch based on v5.3-rc1 containing just the first ESSIV patch (once Herbert is happy with it), and merge that both into cryptodev and dm. That way, both will continue to work without having too much overlap. Since adding a template/file that has no users yet is highly unlikely to break anything, it doesn't even matter which branch gets pulled first. Any idea about the status of the EBOIV patch? -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On 16/08/2019 10:18, Ard Biesheuvel wrote: > On Fri, 16 Aug 2019 at 10:29, Milan Broz <gmazyland@gmail.com> wrote: >> >> Hi Ard, >> >> On 15/08/2019 21:28, Ard Biesheuvel wrote: >>> Changes since v10: >>> - Drop patches against fscrypt and dm-crypt - these will be routed via the >>> respective maintainer trees during the next cycle >> >> I tested the previous dm-crypt patches (I also try to keep them in my kernel.org tree), >> it works and looks fine to me (and I like the final cleanup :) >> >> Once all maintainers are happy with the current state, I think it should go to >> the next release (5.4; IMO both ESSIV API and dm-crypt changes). >> Maybe you could keep sending dm-crypt patches in the end of the series (to help testing it)? >> > > OK. But we'll need to coordinate a bit so that the first patch (the > one that introduces the template) is available in both branches, > otherwise ESSIV will be broken in the dm branch until it hits another > branch (-next or mainline) that also contains cryptodev. Yes, I know. I'll ask Mike what is his preference here... For now, it should appear at least in the cryptodev tree :) ... > Any idea about the status of the EBOIV patch? It is in the queue for 5.4 (should be in linux-next already), I guess 5.4 target is ok here. https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-5.4 Milan -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
This series creates an ESSIV template that produces a skcipher or AEAD transform based on a tuple of the form '<skcipher>,<shash>' (or '<aead>,<shash>' for the AEAD case). It exposes the encapsulated sync or async skcipher/aead by passing through all operations, while using the cipher/shash pair to transform the input IV into an ESSIV output IV. Changes since v11: - Avoid spawns for the ESSIV shash and cipher algos. Instead, the shash TFM is allocated per-instance (which is appropriate since it is unkeyed and thus stateless), and the cipher is allocated explicitly based on the parsed skcipher/aead cra_name. Changes since v10: - Drop patches against fscrypt and dm-crypt - these will be routed via the respective maintainer trees during the next cycle - Fix error handling when parsing the cipher name from the skcipher cra_name - Use existing ivsize temporary instead of retrieving it again - Expose cra_name via module alias (#4) Changes since v9: - Fix cipher_api parsing bug that was introduced by dropping the cipher name parsing patch in v9 (#3). Thanks to Milan for finding it. - Fix a couple of instances where the old essiv(x,y,z) format was used in comments instead of the essiv(x,z) format we adopted in v9 Changes since v8: - Remove 'cipher' argument from essiv() template, and instead, parse the cra_name of the skcipher to obtain the cipher. This is slightly cleaner than what dm-crypt currently does, since we can get the cra_name from the spawn, and we don't have to actually allocate the TFM. Since this implies that dm-crypt does not need to provide the cipher, we can drop the parsing code from it entirely (assuming the eboiv patch I sent out recently is applied first) (patch #7) - Restrict the essiv() AEAD instantiation to AEADs whose cra_name starts with 'authenc(' - Rebase onto cryptodev/master - Drop dm-crypt to reorder/refactor cipher name parsing, since it was wrong and it is no longer needed. - Drop Milan's R-b since the code has changed - Fix bug in accelerated arm64 implementation. Changes since v7: - rebase onto cryptodev/master - drop change to ivsize in #2 - add Milan's R-b's Changes since v6: - make CRYPTO_ESSIV user selectable so we can opt out of selecting it even if FS_ENCRYPTION (which cannot be built as a module) is enabled - move a comment along with the code it referred to (#3), not that this change and removing some redundant braces makes the diff look totally different - add Milan's R-b to #3 and #4 Changes since v5: - drop redundant #includes and drop some unneeded braces (#2) - add test case for essiv(authenc(hmac(sha256),cbc(aes)),aes,sha256) - make ESSIV driver deal with assoc data that is described by more than two scatterlist entries - this only happens when the extended tests are being performed, so don't optimize for it - clarify that both fscrypt and dm-crypt only use ESSIV in special cases (#7) Changes since v4: - make the ESSIV template IV size equal the IV size of the encapsulated cipher - defining it as 8 bytes was needlessly restrictive, and also complicated the code for no reason - add a missing kfree() spotted by Smatch - add additional algo length name checks when constructing the essiv() cipher name - reinstate the 'essiv' IV generation implementation in dm-crypt, but make its generation function identical to plain64le (and drop the other methods) - fix a bug in the arm64 CE/NEON code - simplify the arm64 code by reusing more of the existing CBC implementation (patch #6 is new to this series and was added for this reason) Changes since v3: - address various review comments from Eric on patch #1 - use Kconfig's 'imply' instead of 'select' to permit CRYPTO_ESSIV to be enabled as a module or disabled entirely even if fscrypt is compiled in (#2) - fix an issue in the AEAD encrypt path caused by the IV being clobbered by the inner skcipher before the hmac was being calculated Changes since v2: - fixed a couple of bugs that snuck in after I'd done the bulk of my testing - some cosmetic tweaks to the ESSIV template skcipher setkey function to align it with the aead one - add a test case for essiv(cbc(aes),aes,sha256) - add an accelerated implementation for arm64 that combines the IV derivation and the actual en/decryption in a single asm routine Code can be found here https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=essiv-v11 Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Eric Biggers <ebiggers@google.com> Cc: dm-devel@redhat.com Cc: linux-fscrypt@vger.kernel.org Cc: Gilad Ben-Yossef <gilad@benyossef.com> Cc: Milan Broz <gmazyland@gmail.com> Ard Biesheuvel (4): crypto: essiv - create wrapper template for ESSIV generation crypto: essiv - add tests for essiv in cbc(aes)+sha256 mode crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk crypto: arm64/aes - implement accelerated ESSIV/CBC mode arch/arm64/crypto/aes-glue.c | 206 +++++-- arch/arm64/crypto/aes-modes.S | 28 + crypto/Kconfig | 28 + crypto/Makefile | 1 + crypto/essiv.c | 645 ++++++++++++++++++++ crypto/tcrypt.c | 9 + crypto/testmgr.c | 14 + crypto/testmgr.h | 497 +++++++++++++++ 8 files changed, 1386 insertions(+), 42 deletions(-) create mode 100644 crypto/essiv.c