From: Milan Broz <gmazyland@gmail.com>
To: Baolin Wang <baolin.wang@linaro.org>,
axboe@kernel.dk, agk@redhat.com, snitzer@redhat.com,
dm-devel@redhat.com
Cc: neilb@suse.com, dan.j.williams@intel.com,
martin.petersen@oracle.com, sagig@mellanox.com,
kent.overstreet@gmail.com, keith.busch@intel.com, tj@kernel.org,
broonie@kernel.org, arnd@arndb.de, linux-block@vger.kernel.org,
linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] md: dm-crypt: Optimize the dm-crypt for XTS mode
Date: Tue, 15 Dec 2015 00:31:52 +0100 [thread overview]
Message-ID: <566F5168.7010905@gmail.com> (raw)
In-Reply-To: <02be0f42bf2d3c3d27b43bc050a783582b7af733.1450080755.git.baolin.wang@linaro.org>
On 12/14/2015 09:23 AM, Baolin Wang wrote:
> In now dm-crypt code, it is ineffective to map one bio with just only
> one scatterlist at one time for XTS mode. We can use multiple scatterlists
> to map the whole bio and send all scatterlists of one bio to crypto engine
> to encrypt or decrypt, which can improve the hardware engine's efficiency.
...
> + /*
> + * Here we need to check if it can be encrypted or decrypted with
> + * bulk block, which means these encryption modes don't need IV or
> + * just need one initial IV. For bulk mode, we can expand the
> + * scatterlist entries to map the bio, then send all the scatterlists
> + * to the hardware engine at one time to improve the crypto engine
> + * efficiency. But it does not fit for other encryption modes, it has
> + * to do encryption and decryption sector by sector because every
> + * sector has different IV.
> + */
> + if (!strcmp(chainmode, "ecb") || !strcmp(chainmode, "xts"))
> + cc->bulk_crypto = 1;
> + else
> + cc->bulk_crypto = 0;n
It is perfectly fine to use another IV even for XTS mode (despite it is not needed).
You can use ESSIV for example, or benbi (big-endian variant of plain IV).
(And it is really used for some LUKS devices.)
How it is supposed to work in this case?
If I read this patch correctly, it will completely corrupt data in this case because
it expects plain (consecutive) IV...
Also how it handles 32bit plain IV (that restart after 2TB)? (IOW plain IV, not plain64).
Milan
next prev parent reply other threads:[~2015-12-14 23:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 8:23 [PATCH 0/2] Optimize the dm-crypt for XTS mode Baolin Wang
2015-12-14 8:23 ` [PATCH 1/2] block: Export the __blk_bios_map_sg() to map one bio Baolin Wang
2015-12-14 8:23 ` [PATCH 2/2] md: dm-crypt: Optimize the dm-crypt for XTS mode Baolin Wang
2015-12-14 23:31 ` Milan Broz [this message]
2015-12-15 2:56 ` Baolin Wang
2015-12-15 8:20 ` Milan Broz
2015-12-15 11:35 ` Baolin Wang
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=566F5168.7010905@gmail.com \
--to=gmazyland@gmail.com \
--cc=agk@redhat.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=baolin.wang@linaro.org \
--cc=broonie@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dm-devel@redhat.com \
--cc=keith.busch@intel.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=neilb@suse.com \
--cc=sagig@mellanox.com \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).