On 15 June 2016 at 14:49, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > 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. Ah, sorry. Would you check this thread? http://lkml.iu.edu/hypermail/linux/kernel/1601.1/03829.html > > 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. But that means we should divide the bulk request into 512-byte size requests and break up the mapped sg table for each request. Another hand we should allocate memory for each request in crypto layer, which dm-crypt have supplied one high efficiency way. I think these are really top level how to use the crypro APIs, does that need to move into crypto laryer? Thanks. > > Cheers, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
