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

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

 



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


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

  Powered by Linux