> 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);
Seems like the same thing to me. Kim is inclined towards removing the memset completely, which I think should not be done. We need the memset to clear the entire key table. > 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? Correct. Will fix this. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
