Re: crypto API - async semantics

[Horia Geantă]

On 10/12/2017 12:49 PM, Herbert Xu wrote:
> On Thu, Oct 12, 2017 at 09:39:34AM +, Horia Geantă wrote:
>>
>> Taking ascii art from crypto API docs:
>>
>> DATA ---.
>> v
>>  .init() -> .update() -> .final()  ! .update() might not be called
>>  ^| |at all in this scenario.
>>  '' '---> HASH
>>
>> My question was referring to the case where multiple update() operations
>> are issued in parallel for the same request object.
>> For e.g. let's say a crypto API client wants to hash a 4GB file, and
>> does this by issuing update() repeatedly and performing
>> wait_for_completion() at the very end.
> 
> That is most certainly not legal.  Is dm-crypt doing that?
> 
dm-crypt is issuing requests (aead / skcipher) in parallel, however a
new request object is allocated each time, which seems legit.

My confusion was due to mixing parallelism at different levels:
-at request object level - issuing multiple requests for the same
request object (ahash update() case)
-at tfm object level - issuing multiple requests for different request
objects (dm-crypt case)

As you pointed out, the first is not legal, while the latter is
perfectly fine.

Thanks,
Horia

Re: crypto API - async semantics

[Herbert Xu]

On Thu, Oct 12, 2017 at 09:39:34AM +, Horia Geantă wrote:
>
> Taking ascii art from crypto API docs:
> 
> DATA ---.
> v
>  .init() -> .update() -> .final()  ! .update() might not be called
>  ^| |at all in this scenario.
>  '' '---> HASH
> 
> My question was referring to the case where multiple update() operations
> are issued in parallel for the same request object.
> For e.g. let's say a crypto API client wants to hash a 4GB file, and
> does this by issuing update() repeatedly and performing
> wait_for_completion() at the very end.

That is most certainly not legal.  Is dm-crypt doing that?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: crypto API - async semantics

[Horia Geantă]

On 10/12/2017 9:44 AM, Herbert Xu wrote:
> On Wed, Oct 11, 2017 at 12:36:11PM +, Horia Geantă wrote:
>> Hi Herbert,
>>
>> I am evaluating whether ahash implementation in caam crypto driver
>> behaves correctly.
>> One thing I've noticed is that for each ahash tfm there is support for
>> at most two in-flight requests, and I would like to know whether this is
>> an issue or not.
> 
> What do you mean by in-flight requests? If you're talking about
> requests that have not been completed (i.e., in progress) then
> that's fine.  Any new requests coming in can just be queued.
> 
> If you're talking about requests that have not been finalised
> then that would be broken.  The API allows an arbitrary number
> of requests to ben present in an non-finalised state.  For example,
> given an IPsec SA, we may be processing any number of packets for
> it at once, with each coming from a different CPU.
> 
Taking ascii art from crypto API docs:

DATA ---.
v
 .init() -> .update() -> .final()  ! .update() might not be called
 ^| |at all in this scenario.
 '' '---> HASH

My question was referring to the case where multiple update() operations
are issued in parallel for the same request object.
For e.g. let's say a crypto API client wants to hash a 4GB file, and
does this by issuing update() repeatedly and performing
wait_for_completion() at the very end.

>> In this context, could you please clarify whether your previous answer:
>> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg04029.html
>>> If any async operation returns EINPROGRESS, the client must not
>>> proceed until that operation has completed.
>> refers only to ahash operations OR to any crypto API async operation?
>> IIUC this would be equivalent to saying that crypto API allows only for
>> one in-flight request per tfm, correct?
> 
> No that comment is referring to the request object.  The whole point
> of having a request object is to allow arbitrary number of hash
> operations in parallel given a single tfm.  The tfm is simply a
> representation of the key.  All hash state must be stored in the
> request.
> 
Got it, thanks.

Horia

Re: crypto API - async semantics

[Herbert Xu]

On Wed, Oct 11, 2017 at 12:36:11PM +, Horia Geantă wrote:
> Hi Herbert,
> 
> I am evaluating whether ahash implementation in caam crypto driver
> behaves correctly.
> One thing I've noticed is that for each ahash tfm there is support for
> at most two in-flight requests, and I would like to know whether this is
> an issue or not.

What do you mean by in-flight requests? If you're talking about
requests that have not been completed (i.e., in progress) then
that's fine.  Any new requests coming in can just be queued.

If you're talking about requests that have not been finalised
then that would be broken.  The API allows an arbitrary number
of requests to ben present in an non-finalised state.  For example,
given an IPsec SA, we may be processing any number of packets for
it at once, with each coming from a different CPU.

> In this context, could you please clarify whether your previous answer:
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg04029.html
> > If any async operation returns EINPROGRESS, the client must not
> > proceed until that operation has completed.
> refers only to ahash operations OR to any crypto API async operation?
> IIUC this would be equivalent to saying that crypto API allows only for
> one in-flight request per tfm, correct?

No that comment is referring to the request object.  The whole point
of having a request object is to allow arbitrary number of hash
operations in parallel given a single tfm.  The tfm is simply a
representation of the key.  All hash state must be stored in the
request.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt