Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1422673
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag |
| Date | 2016-06-15 09:00 +0200 |
| Message-ID | <rKcXT-7xD-1@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> <rKcuR-7lr-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: > > 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 link only points to an email about an oops. Diggin through that thread, the only objection I have seen is about the fact that you have to generate a fresh IV for each sector, which is precisely what I'm suggesting that you do. IOW, implement the IV generators in the crypto API, and then you can easily generate a new IV (if necessary) for each sector. > 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. Of course you would do CBC in 512-byte blocks, but my point is that you should do this in a crypto API algorithm, rather than dm-crypt as we do now. Once you implement that then dm-crypt can treat every algorithm as if they supported bulk processing. Cheers, -- 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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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