On Wed, Nov 29, 2023 at 03:00:48PM +0000, Christophe Leroy wrote:
>
>
> Le 22/10/2023 à 10:10, Eric Biggers a écrit :
> > From: Eric Biggers <ebiggers@xxxxxxxxxx>
> >
> > The crypto API's support for alignmasks for ahash algorithms is nearly
> > useless, as its only effect is to cause the API to align the key and
> > result buffers. The drivers that happen to be specifying an alignmask
> > for ahash rarely actually need it. When they do, it's easily fixable,
> > especially considering that these buffers cannot be used for DMA.
> >
> > In preparation for removing alignmask support from ahash, this patch
> > makes the talitos driver no longer use it. This driver didn't actually
> > rely on it; it only writes to the result buffer in
> > common_nonsnoop_hash_unmap(), simply using memcpy(). And this driver's
> > "ahash_setkey()" function does not assume any alignment for the key
> > buffer.
>
> I can't really see the link between your explanation and commit
> c9cca7034b34 ("crypto: talitos - Align SEC1 accesses to 32 bits
> boundaries.").
>
> Was that commit wrong ?
>
> Christophe
Commit c9cca7034b34 ("crypto: talitos - Align SEC1 accesses to 32 bits
boundaries.") added an alignmask to all algorithm types: skcipher, aead, and
ahash. The commit did not explain why it was needed for each algorithm type,
and its true necessity may have varied by algorithm type. In the case of
ahashes, the alignmask may have been needed originally, but commit 7a6eda5b8d9d
("crypto: talitos - fix hash result for VMAP_STACK") made it unnecessary.
- Eric
