From: Milan Broz <gmazyland@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Xiongfeng Wang <wangxiongfeng2@huawei.com>,
agk@redhat.com, snitzer@redhat.com, herbert@gondor.apana.org.au,
dm-devel@redhat.com, linux-kernel@vger.kernel.org, arnd@arndb.de,
jonathan.cameron@huawei.com
Subject: Re: [PATCH 4/5] crypto: Add IV generation templates
Date: Wed, 18 Jul 2018 19:17:45 +0200 [thread overview]
Message-ID: <82248c13-42fe-b598-0cd7-68e5db0b51be@gmail.com> (raw)
In-Reply-To: <20180718164625.GA20360@sirena.org.uk>
On 18/07/18 18:46, Mark Brown wrote:
> On Wed, Jul 18, 2018 at 10:16:05AM +0200, Milan Broz wrote:
>
>> So we are here again and moving INTERNAL dm-crypt functionality into
>> cryptoapi.
>
>> The TCW,LMK IVs generator make sense only for dm-crypt
>> for compatible old disk encryption mappings.
>
>> I strongly disagree to move this outside of dm-crypt.
>
>> Sorry, the last discussion was that it remains inside dm-crypt
>> and it will be only registered through crypto API.
>
> Sorry, I'm partly to blame for this in that I asked Xiongfeng to pick up
> Binoy Jayan's old patch set. I seem to have missed that particular part
> of the discussion and so haven't forwarded it on to him - do you have a
> link, I can't seem to see it in my local archives of the prior
> discussions but they might not be complete?
I think the last iteration was this patch
https://lore.kernel.org/lkml/1498106510-19793-2-git-send-email-binoy.jayan@linaro.org/
But I have still some questions, because I really do not understand
the real reason for this patchset.
For now, it adds a lot of complexity for ... what?
1) If the reason is to make cryptoapi to include IV algorithms, I think we should
focus on universal algorithms (sequential aka plain64 in dmcrypt) as used
in XTS mode. ESSIV is intended for CBC mode only and I think general
consensus today is that XTS mode is preferred to CBC (despite it known problems).
But I see ESSIV used elsewhere, so maybe it makes sense to export this one as well.
But definitely not other internal IVs - some IV generators inside dm-crypt
(namely TCW and LMK) do much more that IV - they modify encryption mode.
This was a hack to support some FDE encryption modes (old Truecrypt and loopAES)
and that should not spread outside dm-crypt (and blame me for this code hacks :).
2) If the reason is performance, please provide numbers with the patch.
What I see now is that the performance is almost the same. So why you are doing it?
Any real hw that benefits from it?
I added 4k sector support in dmcrypt and IMO this helps much more
than some hw IV accelerations (AFAIK is is already used in some mainframe
accelerators this way because of performance).
Milan
next prev parent reply other threads:[~2018-07-18 17:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 7:30 [PATCH 0/5] crypto: add " Xiongfeng Wang
2018-07-18 7:30 ` [PATCH 1/5] crypto: api - introduce API to (un)register a array of templates Xiongfeng Wang
2018-07-18 7:30 ` [PATCH 2/5] crypto: ccm - use template array registering API to simplify the code Xiongfeng Wang
2018-07-18 7:30 ` [PATCH 3/5] crypto: gcm " Xiongfeng Wang
2018-07-18 7:30 ` [PATCH 4/5] crypto: Add IV generation templates Xiongfeng Wang
2018-07-18 8:16 ` Milan Broz
2018-07-18 8:48 ` Xiongfeng Wang
2018-07-18 13:11 ` Mike Snitzer
2018-07-18 16:46 ` Mark Brown
2018-07-18 17:17 ` Milan Broz [this message]
2018-07-18 17:47 ` Mark Brown
2018-07-19 1:46 ` Xiongfeng Wang
2018-07-19 8:50 ` Arnd Bergmann
2018-07-19 8:54 ` Herbert Xu
2018-07-19 13:30 ` Mark Brown
2018-07-19 18:14 ` kbuild test robot
2018-07-18 7:30 ` [PATCH 5/5] dm-crypt: modify dm-crypt to rely on " Xiongfeng Wang
2018-07-18 10:59 ` [PATCH 0/5] crypto: add " Arnd Bergmann
2018-07-18 15:34 ` Ard Biesheuvel
2018-07-19 10:55 ` Xiongfeng Wang
2018-07-19 14:08 ` Ard Biesheuvel
2018-07-19 15:50 ` Mark Brown
2018-07-20 1:02 ` Ard Biesheuvel
2018-07-20 11:45 ` Mark Brown
2018-07-20 12:23 ` Ard Biesheuvel
2018-07-20 12:32 ` Mark Brown
2018-07-22 13:39 ` Gilad Ben-Yossef
2018-07-23 0:13 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82248c13-42fe-b598-0cd7-68e5db0b51be@gmail.com \
--to=gmazyland@gmail.com \
--cc=agk@redhat.com \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=dm-devel@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=jonathan.cameron@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=snitzer@redhat.com \
--cc=wangxiongfeng2@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®