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.
Uri Simchoni <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt