On 3 June 2016 at 16:21, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote: >> >> Suppose the cbc(aes) algorithm, which can not be handled through bulk >> interface, it need to map the data sector by sector. >> If we also handle the cbc(aes) algorithm with bulk interface, we need >> to divide the sg table into sectors and need to allocate request >> memory for each divided sectors (As Mike pointed out this is in the >> IO mapping >> path and we try to avoid memory allocations at all costs -- due to the >> risk of deadlock when issuing IO to stacked block devices (dm-crypt >> could be part of a much more elaborate IO stack). ), that will >> introduce more messy things I think. > > Perhaps I'm not making myself very clear. If you move the IV > generation into the crypto API, those crypto API algorithms will > be operating at the sector level. Yeah, IV generation is OK. But it is not only related to IV thing. For example: (1) For ecb(aes) algorithm which don't need to handle IV generation, so it can support bulk mode: Assuming one 64K size bio coming , we can map the whole bio with one sg table in dm-crypt (assume it used 16 scatterlists from sg table), then issue the 'skcipher_request_set_crypt()' function to set one request with the mapped sg table, which will be sent to crypto driver to be handled. (2) For cbc(aes) algorithm which need to handle IV generation sector by sector, so it can not support bulk mode and can not use bulk interface: Assuming one 64K size bio coming , we should map the bio sector by sector with one scatterlist at one time. Each time we will issue the 'skcipher_request_set_crypt()' function to set one request with only one mapped scatterlist, until it handled done the whole bio. (3) As your suggestion, if we also use bulk interface for cbc(aes) algorithm assuming it did all the requisite magic to generate the correct IV: Assuming one 64K size bio coming, we can map the whole bio with one sg table in crypt_convert_bulk_block() function. But if we send this bulk request to crypto layer, we should divide the bulk request into small requests, and each small request should be one sector size (512 bytes) with assuming the correct IV, but we need to allocate small requests memory for the division, which will not good for IO mapping, and how each small request connect to dm-crypt (how to notify the request is done?)? Thus we should not handle every algorithm with bulk interface. > > For example, assuming you're doing lmk, then the algorithm would > be called lmk(cbc(aes)) and it will take as its input one or more > sectors and for each sector it should generate an IV and operate > on it. > > 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
