Async hash reentrancy

Async hash reentrancy

[Uri Simchoni]

Hi,

I'd like to add sha1/hmac-sha1 support to the Marvell CESA driver. I couldn't see an ahash driver that I can use as a reference. Is there such a driver?

There's a thing I'm not sure I understand, and that's the init-update-final mechanism. I know what it's for (as in other APIs, e.g. OpenSSL), but I'm not sure how it's supposed to work asynchronously.

Assuming the client code is using the init->update->final sequence (and not just the digest call):
- Should it be using it on the same ahash_request object? (probably yes - that's the whole point...)
- If the same ahash_request object is used, it means the driver has to save the SG info per such call, it cannot simply queue the ahash_request as is often done in crypto drivers, right? I mean, the req->src is changing between crypto_ahash_update() calls.
- Same for callback? (.complete pointer)

Thanks,
Uri.

Re: Async hash reentrancy

[Herbert Xu]

Uri Simchoni <uris@ctera.com> wrote:
> Hi,
> 
> I'd like to add sha1/hmac-sha1 support to the Marvell CESA driver. I couldn't see an ahash driver that I can use as a reference. Is there such a driver?

We did have an implementation but it had to be removed because
it wasn't reentrant so it's not a good model for you to follow
anyway.

> Assuming the client code is using the init->update->final sequence (and not just the digest call):
> - Should it be using it on the same ahash_request object? (probably yes - that's the whole point...)

Yes.

> - If the same ahash_request object is used, it means the driver has to save the SG info per such call, it cannot simply queue the ahash_request as is often done in crypto drivers, right? I mean, the req->src is changing between crypto_ahash_update() calls.

First of all to support init/update/final at all, your hardware
must be able to provide partial hash results in a "standard"
format.  See the export/import interface in sha1 for how that
should work.

Now if your hardware is only able to produce a final result, then
you should simply implement finup + digest, and do the update
operations using a software fallback.

To answer your actual question, a single request supports only one
outstanding operation at a time.  So it is illegal for the user
to issue a new update operation prior to the previous completing.

IOW you have nothing to worry about.

> - Same for callback? (.complete pointer)

Ditto.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt