On Tue, Dec 26, 2017 at 12:40 PM, Herbert Xu
<herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Dec 26, 2017 at 11:06:02AM +0200, Gilad Ben-Yossef wrote:
>>
>> The hash state needs to be DMAed in and out of the hardware on each operation
>> and I have no guarantee that the ahash request is allocated from DMAable memory
>> (i.e. AHASH_REQUEST_ON_STACK).
>
> AHASH_REQUEST_ON_STACK cannot possibly be used on an async ahash
> implementation for obvious reasons so this shouldn't be an issue.
>
OK, you lost me on this statement.
See how SKCIPHER_REQUEST_ON_STACK is being used with an asymmetric skcipher
in drivers/md/dm-integrity.c
The case with AHASH_REQUEST_ON_STACK looks symmetric to me.
E.g. why would this dummy code be illegal -
DECLARE_CRYPTO_WAIT(wait);
AHASH_REQUEST_ON_STACK(req, tfm);
sg_init_table(&sg, 1);
sg_set_buf(&sg, buf);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP |
CRYPTO_TFM_REQ_MAY_BACKLOG,
crypto_req_done, (void *)wait);
ahash_request_set_crypt(req, &sg, NULL, len);
rc = crypto_ahash_digest(req);
/* do some stuff here, possibly stuff that can sleep */
rc = crypto_wait_req(r, wait);
...
> The construct is simply a compatibility aid for sync-only users
> to use the ahash interface.
Please don't get me wrong, I'm not trying to argue. Simply putting the
internal state in the
request context is the simplest most straight forward thing for me. If
you say I don't need
to worry about it I'm fine with that. I just want to understand why
it's OK so I can understand
the system better.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
