Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300141 > unrolled thread

Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the  crypto engine efficiency Milan Broz <gmazyland@gmail.com> - 2016-01-02 23:50 +0100
    Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the  crypto engine efficiency Baolin Wang <baolin.wang@linaro.org> - 2016-01-04 08:00 +0100
    Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the  crypto engine efficiency Mark Brown <broonie@kernel.org> - 2016-01-04 21:20 +0100
      Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the  crypto engine efficiency Baolin Wang <baolin.wang@linaro.org> - 2016-01-06 07:50 +0100
      Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency Arnd Bergmann <arnd@arndb.de> - 2016-01-13 00:40 +0100
        Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving  the crypto engine efficiency Mikulas Patocka <mpatocka@redhat.com> - 2016-01-13 03:20 +0100
          Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency Arnd Bergmann <arnd@arndb.de> - 2016-01-13 11:20 +0100
            Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving  the crypto engine efficiency Mikulas Patocka <mpatocka@redhat.com> - 2016-01-13 16:10 +0100
        Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for  improving the crypto engine efficiency Milan Broz <gmazyland@gmail.com> - 2016-01-13 08:10 +0100
      Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving  the crypto engine efficiency Mikulas Patocka <mpatocka@redhat.com> - 2016-01-13 00:40 +0100
        Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for  improving the crypto engine efficiency Mark Brown <broonie@kernel.org> - 2016-01-13 00:50 +0100
          Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving  the crypto engine efficiency Mikulas Patocka <mpatocka@redhat.com> - 2016-01-13 03:20 +0100
            Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for  improving the crypto engine efficiency Mark Brown <broonie@kernel.org> - 2016-01-14 12:40 +0100

#1300141 — Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On 12/17/2015 08:37 AM, Baolin Wang wrote:
> Hi Milan,
> 
> On 16 December 2015 at 16:08, Milan Broz <gmazyland@gmail.com> wrote:
>> On 12/16/2015 04:18 AM, Baolin Wang wrote:
>>> From the dm-crypt performance report, we found it shows low efficiency
>>> with crypto engine for some mode (like ecb or xts mode). Because in dm
>>> crypt, it will map the IO data buffer with scatterlist, and send the
>>> scatterlist of one bio to the encryption engine, if send more scatterlists
>>> with bigger size at one time, that helps the engine palys best performance,
>>> which means a high encryption speed.
>>>
>>> But now the dm-crypt only map one segment (always one sector) of one bio
>>> with one scatterlist to the crypto engine at one time. which is more
>>> time-consuming and ineffective for the crypto engine. Especially for some
>>> modes which don't need different IV for each sector, we can map the whole
>>> bio with multiple scatterlists to improve the engine performance.
>>>
>>> But this optimization is not support some ciphers and IV modes which should
>>> do sector by sector and need different IV for each sector.
>>>
>>> Change since v1:
>>>  - Introduce one different IV mode.
>>>  - Change the conditions for bulk mode.
>>
>> I tried the patchset on 32bit Intel VM and kernel immediately OOPsed (just tried aes-ecb)...
>>
> 
> I've checked the code and I guess some macros I used with different
> definitions on different arch. Could you please try the new patchset
> with some optimization on your platform? It can work well on my arm
> board. Thanks.

Sorry for delay, I tried to compile it.
It doesn't crash now, but it also does not work.

You usage of IV in XTS mode is not correct - it cannot just work this way,
you have to initialize IV after each block. And just one write not aligned
to your large XTS block will corrupt it.

Did you tried to _read_ data you write to the device?

See this test :

# create  device with your patch
$ echo "test"|cryptsetup create -s 512 -c aes-xts-bulk tst /dev/sdg

# prepare random test file
$ dd if=/dev/urandom of=/src.img bs=1M count=16

# now copy the file to the plaintext device and drop caches
$ dd if=/src.img of=/dev/mapper/tst bs=1M count=16

$ echo 3 > /proc/sys/vm/drop_caches

# and verify that we are (not) reading the same data ...

$ dd if=/dev/mapper/tst of=/dst1.img bs=1M count=16

$ sha256sum /src.img /dst1.img 
5401119fa9975bbeebac58e0b2598bc87247a29e62417f9f58fe200b531602ad  /src.img
e9bf5efa95031fdb5adf618db141f48ed23f71b12c017b8a0cbe0a694f18b979  /dst1.img

(I think only first page-sized block is correct, because without direct-io
it writes in page-sized IOs.)


... or just try to mkfs and mount it
$ mkfs -t ext4  /dev/mapper/tst 

mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 262144 4k blocks and 65536 inodes
...

$ mount /dev/mapper/tst /mnt/tst
mount: wrong fs type, bad option, bad superblock on /dev/mapper/tst,
       missing codepage or helper program, or other error


You approach simply does not work. (It will probably work for ECB mode but it is
unusable in real world.)


Anyway, I think that you should optimize driver, not add strange hw-dependent
crypto modes to dmcrypt. This is not the first crypto accelerator that is just not
suited for this kind of use.

(If it can process batch of chunks of data each with own IV, then it can work
with dmcrypt, but I think such optimized code should be inside crypto API,
not in dmcrypt.)

Milan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1300517

Hi Milan,

On 3 January 2016 at 06:46, Milan Broz <gmazyland@gmail.com> wrote:
>
> Sorry for delay, I tried to compile it.
> It doesn't crash now, but it also does not work.
>
> You usage of IV in XTS mode is not correct - it cannot just work this way,
> you have to initialize IV after each block. And just one write not aligned
> to your large XTS block will corrupt it.
>
> Did you tried to _read_ data you write to the device?
>
> See this test :
>
> # create  device with your patch
> $ echo "test"|cryptsetup create -s 512 -c aes-xts-bulk tst /dev/sdg
>
> # prepare random test file
> $ dd if=/dev/urandom of=/src.img bs=1M count=16
>
> # now copy the file to the plaintext device and drop caches
> $ dd if=/src.img of=/dev/mapper/tst bs=1M count=16
>
> $ echo 3 > /proc/sys/vm/drop_caches
>
> # and verify that we are (not) reading the same data ...
>
> $ dd if=/dev/mapper/tst of=/dst1.img bs=1M count=16
>
> $ sha256sum /src.img /dst1.img
> 5401119fa9975bbeebac58e0b2598bc87247a29e62417f9f58fe200b531602ad  /src.img
> e9bf5efa95031fdb5adf618db141f48ed23f71b12c017b8a0cbe0a694f18b979  /dst1.img
>
> (I think only first page-sized block is correct, because without direct-io
> it writes in page-sized IOs.)
>
>
> ... or just try to mkfs and mount it
> $ mkfs -t ext4  /dev/mapper/tst
>
> mke2fs 1.42.13 (17-May-2015)
> Creating filesystem with 262144 4k blocks and 65536 inodes
> ...
>
> $ mount /dev/mapper/tst /mnt/tst
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/tst,
>        missing codepage or helper program, or other error
>
>
> You approach simply does not work. (It will probably work for ECB mode but it is
> unusable in real world.)
>
>
> Anyway, I think that you should optimize driver, not add strange hw-dependent
> crypto modes to dmcrypt. This is not the first crypto accelerator that is just not
> suited for this kind of use.

Very grateful for your feedback. I'm sorry I didn't check much data
correctness, mostly focus on the encryption speed. It looks like there
are something wrong when I follow your test procedure. I will optimize
the driver and need to be known much about XTS mode to check why it
can not work. Thanks.

>
> (If it can process batch of chunks of data each with own IV, then it can work
> with dmcrypt, but I think such optimized code should be inside crypto API,
> not in dmcrypt.)
>
> Milan



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301044

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jan 02, 2016 at 11:46:08PM +0100, Milan Broz wrote:

> Anyway, I think that you should optimize driver, not add strange hw-dependent
> crypto modes to dmcrypt. This is not the first crypto accelerator that is just not
> suited for this kind of use.

> (If it can process batch of chunks of data each with own IV, then it can work
> with dmcrypt, but I think such optimized code should be inside crypto API,
> not in dmcrypt.)

The flip side of this is there is an awful lot of hardware out there
that has basically this pattern and if we can make the difference
between people being able to encrypt or not encrypt their storage due to
performance then that seems like a win.  Getting hardware changes isn't
going to be a fast process.  From a brief look at the crypto layer it
does look there may be things we can do there, if only in terms of
factoring out the common patterns for driving the queue of operations
into the hardware so it's easy for drivers to do the best thing.  

One thing that occurs to me for the IV programming that has been
proposed for SPI by Martin Sparl (and seen good results on Raspberry PI)
is to insert transfers programming the crypto engine into the stream of
DMA operations so we can keep the hardware busy.  It won't work with
every SoC out there but it will work with a lot of them, it's what
hardware that explicitly supports this will be doing internally.  It's
the sort of thing that would benefit from factoring out, it's a lot of
hassle to implement per driver.

The main thing the out of tree req-dm-crypt code is doing was using a
larger block size which does seem like a reasonable thing to allow
people to tune for performance tradeofffs but I undertand that's a lot
harder to achieve in a good way than one might hope.

[toc] | [prev] | [next] | [standalone]

#1302415

On 5 January 2016 at 04:13, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Jan 02, 2016 at 11:46:08PM +0100, Milan Broz wrote:
>
>> Anyway, I think that you should optimize driver, not add strange hw-dependent
>> crypto modes to dmcrypt. This is not the first crypto accelerator that is just not
>> suited for this kind of use.
>
>> (If it can process batch of chunks of data each with own IV, then it can work
>> with dmcrypt, but I think such optimized code should be inside crypto API,
>> not in dmcrypt.)
>
> The flip side of this is there is an awful lot of hardware out there
> that has basically this pattern and if we can make the difference
> between people being able to encrypt or not encrypt their storage due to
> performance then that seems like a win.  Getting hardware changes isn't

Yeah, Now many vendors will supply AES hardware engine to improve the
encryption speed. Like Qualcom or Spreadtrum, they both support the
AES engine, which can handle the IV things in engine interior. So it
can handle bulk data with just one initial IV, which is implemented in
the out of tree req-dm-crypt code. That is why Milan's testing is
failed, cause there is no hardware engine to support this.

> going to be a fast process.  From a brief look at the crypto layer it
> does look there may be things we can do there, if only in terms of
> factoring out the common patterns for driving the queue of operations
> into the hardware so it's easy for drivers to do the best thing.
>
> One thing that occurs to me for the IV programming that has been
> proposed for SPI by Martin Sparl (and seen good results on Raspberry PI)
> is to insert transfers programming the crypto engine into the stream of
> DMA operations so we can keep the hardware busy.  It won't work with
> every SoC out there but it will work with a lot of them, it's what
> hardware that explicitly supports this will be doing internally.  It's
> the sort of thing that would benefit from factoring out, it's a lot of
> hassle to implement per driver.
>
> The main thing the out of tree req-dm-crypt code is doing was using a
> larger block size which does seem like a reasonable thing to allow
> people to tune for performance tradeofffs but I undertand that's a lot
> harder to achieve in a good way than one might hope.



-- 
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1307915 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote:
> 
> Another possibility is to use dm-crypt block size 4k and use a filesystem 
> with 4k blocksize on it (it will never send requests not aligned on 4k 
> boundary, so we could reject such requests with an error).

Is there ever a reason to use something other than 4K block size on
dm-crypt?

	Arnd

[toc] | [prev] | [next] | [standalone]

#1307980 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On Wed, 13 Jan 2016, Arnd Bergmann wrote:

> On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote:
> > 
> > Another possibility is to use dm-crypt block size 4k and use a filesystem 
> > with 4k blocksize on it (it will never send requests not aligned on 4k 
> > boundary, so we could reject such requests with an error).
> 
> Is there ever a reason to use something other than 4K block size on
> dm-crypt?
> 
> 	Arnd

You can't use 4k block on CBC (and most other encryption modes). If only a 
part of 4k block is written (and then system crash happens), CBC would 
corrupt the block completely.

For example, suppose that EXT2 directory block is updated, the first 
512-byte sector is written and the rest of the sectors is not written 
because of a crash. CBC would corrupt all sectors except the first one in 
this case.

You could use 4k block on XTS and ECB.

Mikulas

[toc] | [prev] | [next] | [standalone]

#1308246 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On Tuesday 12 January 2016 21:18:12 Mikulas Patocka wrote:
> On Wed, 13 Jan 2016, Arnd Bergmann wrote:
> 
> > On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote:
> > > 
> > > Another possibility is to use dm-crypt block size 4k and use a filesystem 
> > > with 4k blocksize on it (it will never send requests not aligned on 4k 
> > > boundary, so we could reject such requests with an error).
> > 
> > Is there ever a reason to use something other than 4K block size on
> > dm-crypt?
> > 
> >       Arnd
> 
> You can't use 4k block on CBC (and most other encryption modes). If only a 
> part of 4k block is written (and then system crash happens), CBC would 
> corrupt the block completely.
> 
> For example, suppose that EXT2 directory block is updated, the first 
> 512-byte sector is written and the rest of the sectors is not written 
> because of a crash. CBC would corrupt all sectors except the first one in 
> this case.
> 
> You could use 4k block on XTS and ECB.

Ah, I did not know that ext2 was doing sub-block writes. This may be
something to address in the ext4 code (and other file systems), as
a lot of flash storage devices (SD cards and eMMC) get really slow
when you do writes smaller than 4K because of the internal
read-modify-write cycle. Ideally you want to always drive those
using 64K writes (for reads, it doesn't matter much).

For hard drives, there are still a couple of older models that have
native 512 byte sectors, but the majority of new drivers also
prefers 4K writes. SSDs are typically optimized for 4K writes because
that is what they expect software to do, but they use larger writes
internally.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1308487 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On Wed, 13 Jan 2016, Arnd Bergmann wrote:

> On Tuesday 12 January 2016 21:18:12 Mikulas Patocka wrote:
> > On Wed, 13 Jan 2016, Arnd Bergmann wrote:
> > 
> > > On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote:
> > > > 
> > > > Another possibility is to use dm-crypt block size 4k and use a filesystem 
> > > > with 4k blocksize on it (it will never send requests not aligned on 4k 
> > > > boundary, so we could reject such requests with an error).
> > > 
> > > Is there ever a reason to use something other than 4K block size on
> > > dm-crypt?
> > > 
> > >       Arnd
> > 
> > You can't use 4k block on CBC (and most other encryption modes). If only a 
> > part of 4k block is written (and then system crash happens), CBC would 
> > corrupt the block completely.
> > 
> > For example, suppose that EXT2 directory block is updated, the first 
> > 512-byte sector is written and the rest of the sectors is not written 
> > because of a crash. CBC would corrupt all sectors except the first one in 
> > this case.
> > 
> > You could use 4k block on XTS and ECB.
> 
> Ah, I did not know that ext2 was doing sub-block writes. This may be

Ext2 is not doing sub-block writes.

Generally, disks and SSDs do not guarantee 4k write atomicity (only disks 
with hardware 4k sector guarantee it).

For example, ext2 writes a full 4k block, only part of the block is 
written to the disk and then power failure happens. On the next reboot CBC 
will corrupt the unwritten part of the 4k block.

Mikulas

> something to address in the ext4 code (and other file systems), as
> a lot of flash storage devices (SD cards and eMMC) get really slow
> when you do writes smaller than 4K because of the internal
> read-modify-write cycle. Ideally you want to always drive those
> using 64K writes (for reads, it doesn't matter much).
> 
> For hard drives, there are still a couple of older models that have
> native 512 byte sectors, but the majority of new drivers also
> prefers 4K writes. SSDs are typically optimized for 4K writes because
> that is what they expect software to do, but they use larger writes
> internally.
> 
> 	Arnd
> 

[toc] | [prev] | [next] | [standalone]

#1308103 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On 01/13/2016 12:38 AM, Arnd Bergmann wrote:
> On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote:
>>
>> Another possibility is to use dm-crypt block size 4k and use a filesystem 
>> with 4k blocksize on it (it will never send requests not aligned on 4k 
>> boundary, so we could reject such requests with an error).
> 
> Is there ever a reason to use something other than 4K block size on
> dm-crypt?

Most existing sw FDE systems use 512bytes blocks. I would like to see
configurable block size (at least up to 4k) but as Mikulas pointed out
it opens several new problems. 

Anyway, I do not see reason why crypto accelerators should not process
these small sectors better - just hw must be designed for it.

Milan

[toc] | [prev] | [next] | [standalone]

#1307920 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On Mon, 4 Jan 2016, Mark Brown wrote:

> On Sat, Jan 02, 2016 at 11:46:08PM +0100, Milan Broz wrote:
> 
> > Anyway, I think that you should optimize driver, not add strange hw-dependent
> > crypto modes to dmcrypt. This is not the first crypto accelerator that is just not
> > suited for this kind of use.
> 
> > (If it can process batch of chunks of data each with own IV, then it can work
> > with dmcrypt, but I think such optimized code should be inside crypto API,
> > not in dmcrypt.)
> 
> The flip side of this is there is an awful lot of hardware out there
> that has basically this pattern and if we can make the difference
> between people being able to encrypt or not encrypt their storage due to
> performance then that seems like a win.  Getting hardware changes isn't
> going to be a fast process.  From a brief look at the crypto layer it
> does look there may be things we can do there, if only in terms of
> factoring out the common patterns for driving the queue of operations
> into the hardware so it's easy for drivers to do the best thing.  
> 
> One thing that occurs to me for the IV programming that has been
> proposed for SPI by Martin Sparl (and seen good results on Raspberry PI)
> is to insert transfers programming the crypto engine into the stream of
> DMA operations so we can keep the hardware busy.  It won't work with
> every SoC out there but it will work with a lot of them, it's what
> hardware that explicitly supports this will be doing internally.  It's
> the sort of thing that would benefit from factoring out, it's a lot of
> hassle to implement per driver.
> 
> The main thing the out of tree req-dm-crypt code is doing was using a
> larger block size which does seem like a reasonable thing to allow
> people to tune for performance tradeofffs but I undertand that's a lot
> harder to achieve in a good way than one might hope.

But as Milan pointed out, that larger block size doesn't work if you 
process requests with different sizes - the data encrypted with one 
request size won't match if you decrypt them with a different request 
size.


XTS with larger block could work if it were possible to use arbitrary 
initial tweak - the function crypt() in crypto/xts.c calculates the 
initial sector tweak by encrypting the iv:

tw(crypto_cipher_tfm(ctx->tweak), w->iv, w->iv);

and then calculates each cipher block's tweak by multiplying the tweak by 
a constant polynomial (alpha):

gf128mul_x_ble(s.t, s.t);	(s.t is the same as w->iv)


If we could supply the tweak directly, we could use larger sectors in 
dm-crypt.

For example, we could use 64k XTS sectors and if the user is accessing 1k 
offset in the sector, we could calculate initial sector tweak
	tw(crypto_cipher_tfm(ctx->tweak), w->iv, w->iv);
and then multiply it by alpha^(1024/16) (because we are 1024 bytes into 
the sector and xts block size is 16). That would make it possible to use 
larger encryption requests and the data would match regardless of request 
size.

But the Linux crypto API doesn't allow this - the code that would multiply 
the tweak after initial encryption isn't there (maybe we could get this 
behavior by modifying ctx->tweak to point to a null cipher, but it is 
dirty hack to poke into private crypto structures).

Does the hardware encryption you are optimizing for allow setting 
arbitrary tweaks in XTS mode? What is the specific driver you are 
optimizing for?


Another possibility is to use dm-crypt block size 4k and use a filesystem 
with 4k blocksize on it (it will never send requests not aligned on 4k 
boundary, so we could reject such requests with an error).

Mikulas

[toc] | [prev] | [next] | [standalone]

#1307922 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 12, 2016 at 06:31:19PM -0500, Mikulas Patocka wrote:
> On Mon, 4 Jan 2016, Mark Brown wrote:

> > The main thing the out of tree req-dm-crypt code is doing was using a
> > larger block size which does seem like a reasonable thing to allow
> > people to tune for performance tradeofffs but I undertand that's a lot
> > harder to achieve in a good way than one might hope.

> But as Milan pointed out, that larger block size doesn't work if you 
> process requests with different sizes - the data encrypted with one 
> request size won't match if you decrypt them with a different request 
> size.

Sure, you need to fix that block size.

> Does the hardware encryption you are optimizing for allow setting 
> arbitrary tweaks in XTS mode? What is the specific driver you are 
> optimizing for?

This isn't targeted at a specific driver or system, it's trying to make
dm-crypt better able to make use of hardware acceleration in general.

[toc] | [prev] | [next] | [standalone]

#1307984 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On Tue, 12 Jan 2016, Mark Brown wrote:

> On Tue, Jan 12, 2016 at 06:31:19PM -0500, Mikulas Patocka wrote:
> > On Mon, 4 Jan 2016, Mark Brown wrote:
> 
> > > The main thing the out of tree req-dm-crypt code is doing was using a
> > > larger block size which does seem like a reasonable thing to allow
> > > people to tune for performance tradeofffs but I undertand that's a lot
> > > harder to achieve in a good way than one might hope.
> 
> > But as Milan pointed out, that larger block size doesn't work if you 
> > process requests with different sizes - the data encrypted with one 
> > request size won't match if you decrypt them with a different request 
> > size.
> 
> Sure, you need to fix that block size.
> 
> > Does the hardware encryption you are optimizing for allow setting 
> > arbitrary tweaks in XTS mode? What is the specific driver you are 
> > optimizing for?
> 
> This isn't targeted at a specific driver or system, it's trying to make
> dm-crypt better able to make use of hardware acceleration in general.

If the hardware acceleration doesn't allow to set arbitrary XTS tweak, 
then this "large block" optimization on XTS can't be done at all.

So, we need to know which driver(s) you want to optimize for and how do 
those driver(s) handle tweak generation.

Mikulas

[toc] | [prev] | [next] | [standalone]

#1309197 — Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 12, 2016 at 09:13:19PM -0500, Mikulas Patocka wrote:
> On Tue, 12 Jan 2016, Mark Brown wrote:

> > This isn't targeted at a specific driver or system, it's trying to make
> > dm-crypt better able to make use of hardware acceleration in general.

> If the hardware acceleration doesn't allow to set arbitrary XTS tweak, 
> then this "large block" optimization on XTS can't be done at all.

> So, we need to know which driver(s) you want to optimize for and how do 
> those driver(s) handle tweak generation.

Unfortunately the reality is just as I described it - we're looking for
general improvements, not at specific devices (well, Linaro is mainly
interested in ARM based SoCs but the range of ARM SoCs is such that that
that doesn't really narrow things down).  It's probably better to ask if
there exists any hardware which could use this usefully, software only
implementations (or hardware that only does AES) at least give us
control over supplying the tweak.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web