From: Milan Broz <gmazyland@gmail.com>
To: Dinesh Garg <dinesh.garg@gmail.com>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Encrypting with larger packet size
Date: Tue, 22 Jan 2013 16:54:47 +0100 [thread overview]
Message-ID: <50FEB647.8060005@gmail.com> (raw)
In-Reply-To: <CAO6to9VvrtoFEr6XE29YOMbpdO+vD23S37LCi07e64u-F38Dgg@mail.gmail.com>
On 01/22/2013 09:00 AM, Dinesh Garg wrote:
> I think HW accelerator is an issue with smaller packet size because:
> 1. It takes time to switch the context from software to hardware ( i.e. interrupt handling)
> 2. HW accelerators dont allow multiple crypto operations at the same time due to security reasons
I think all these problems are technically solvable but that's
not discussion for dmcrypt list...
> What do you mean by DM operates at 512B level? Is it that DM always
> calls dmcrypt with 512B data even if file system is 4K block size?
Everything in block layer is calculated in sectors of 512 bytes size,
just for bigger sector size proper alignment is required.
(So if we support, say 8k block, we must _force_ all layers to use only
8k block. Otherwise you will get data corruption.)
> I tried aggregating scatter gather list at the crypto driver layer
> but it did not work because DM supposedly operates at 512B. Sending
> multiple encryptions commands to HW CE does not help due to CE setup
> time etc.
As I said above, you have force DM/block layer to accept only
properly sized requests. Otherwise I do not see problem in crypto layer.
(This should be simulated with kernel cryptd() driver even without
proper crypto hw, just it need some hacking.)
> dm-crypt is excellent block driver encryption solution. If anyone can
> guide me, I would like to contribute as this is problem faced by HW
> accelerator( I read several mails in the archive).
Please can you be more specific?
Which HW accelerator you are using, where is the source of it and
when it will be part of upstream kernel? (if not already).
But as I said, the patch for dmcrypt is not complicated, it
is incompatibility later which this can cause.
So I would really like to see strong reason before we implement
direct support for larger sectors.
> As per my understanding, AES-NI is not supported on arm based
> chipset.
Sure, that was just an example. But I am sure that even on ARM you can
do hw acceleration which works with 512 bytes sectors.
Even if we provide option to use bigger block size, it will not
be compatible with LUKS devices and other encryption schemes
(like TrueCrypt) which use 512 block always.
Milan
next prev parent reply other threads:[~2013-01-22 16:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 4:18 [dm-crypt] Encrypting with larger packet size Dinesh Garg
2013-01-22 5:42 ` Arno Wagner
2013-01-22 6:04 ` Dinesh Garg
2013-01-22 7:24 ` Milan Broz
2013-01-22 8:00 ` Dinesh Garg
2013-01-22 15:54 ` Milan Broz [this message]
2013-01-24 19:44 ` Dinesh Garg
2013-01-25 23:25 ` Arno Wagner
2013-01-28 12:00 ` [dm-crypt] Encrypting with larger packet size (+some experimental patch) Milan Broz
2013-03-05 11:53 ` Michael Stapelberg
2013-03-10 15:05 ` Milan Broz
2013-03-25 19:22 ` Michael Stapelberg
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=50FEB647.8060005@gmail.com \
--to=gmazyland@gmail.com \
--cc=dinesh.garg@gmail.com \
--cc=dm-crypt@saout.de \
/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