Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

From	Baolin Wang <baolin.wang@linaro.org>
Newsgroups	linux.kernel
Subject	Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
Date	2016-06-15 08:30 +0200
Message-ID	<rKcuR-7lr-5@gated-at.bofh.it> (permalink)
References	<rHo9b-2Ai-5@gated-at.bofh.it> <rHo9b-2Ai-3@gated-at.bofh.it> <rHq1j-3KB-17@gated-at.bofh.it> <rHB6q-2jK-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Hi Herbert,

On 8 June 2016 at 10:00, Baolin Wang <baolin.wang@linaro.org> wrote:
> Hi Herbert,
>
> On 7 June 2016 at 22:16, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Tue, Jun 07, 2016 at 08:17:05PM +0800, Baolin Wang wrote:
>>> Now some cipher hardware engines prefer to handle bulk block rather than one
>>> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
>>> the intermediate values (IV) by themselves in one bulk block. This means we
>>> can increase the size of the request by merging request rather than always 512
>>> bytes and thus increase the hardware engine processing speed.
>>>
>>> So introduce 'CRYPTO_ALG_BULK' flag to indicate this cipher can support bulk
>>> mode.
>>>
>>> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
>>
>> Nack.  As I said before, please do it using explicit IV generators
>> like we do for IPsec.
>
> OK. I would like to try your suggestion. Thanks.

After some investigation, I still think we should divide the bulk
request from dm-crypt into small request (each one is 512bytes) if
this algorithm is not support bulk mode (like CBC). We have talked
with dm-crypt
maintainers why dm-crypt always use 512 bytes as one request size in
below thread, could you please check it?
http://www.kernelhub.org/?p=2&msg=907022

That means if we move the IV handling into crypto API, we still can
not use bulk interface for all algorithm, for example we still need to
read/write with 512 bytes for CBC, you can't use 4k or more 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. It means if we map one whole bio with bulk interface in
dm-crypt, we need to divide into every 512 bytes requests in crypto
layer. So I don't think we can handle every algorithm with bulk
interface just moving the IV handling into crypto API. Thanks.

>
>> --
>> Email: Herbert Xu <herbert@gondor.apana.org.au>
>> Home Page: http://gondor.apana.org.au/~herbert/
>> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
>
>
> --
> Baolin.wang
> Best Regards

-- 
Baolin.wang
Best Regards

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Baolin Wang <baolin.wang@linaro.org> - 2016-06-15 08:30 +0200
  Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-15 09:00 +0200
    Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Baolin Wang <baolin.wang@linaro.org> - 2016-06-15 09:40 +0200
      Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Herbert Xu <herbert@gondor.apana.org.au> - 2016-06-15 09:50 +0200
        Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag Baolin Wang <baolin.wang@linaro.org> - 2016-06-15 10:50 +0200

csiph-web