Varun Wadekar wrote at Monday, November 14, 2011 9:11 PM: > >> Why? > > To avoid redundant work; there's little point memset()ing a region that's > > going to be copied over the top of immediately afterwards. > > > > The length used for memset is different from the length being copied > over. I am initially memsetting the entire key struct (which contains > the key + original IV + updated IV) and then copying only the key. Down > the line we copy the original IV and/or the updated IV in this memory space. That doesn't make the duplicate memset/copy cease to be redundant. Why not copy the key to where it goes, then memset the rest of the data; wouldn't that be as simple as: memcpy(dd->ivkey_base, ctx->key, ctx->keylen); memset(dd->ivkey_base + ctx->keylen, 0, AES_HW_KEY_TABLE_LENGTH_BYTES - ctx->keylen); Related to this, I wonder why: /* * The key table length is 64 bytes * (This includes first upto 32 bytes key + 16 bytes original initial vector * and 16 bytes updated initial vector) */ #define AES_HW_KEY_TABLE_LENGTH_BYTES 64 Yet: dd->ivkey_base = dma_alloc_coherent(dev, SZ_512, &dd->ivkey_phys_base, ... Why is SZ_512 used to during alloc instead of AES_HW_KEY_TABLE_LENGTH_BYTES? -- nvpublic -- 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
