Re: [PATCH v1] crypto: driver for tegra AES hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux