LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Can an ahash driver be used through shash API?
@ 2019-05-29 14:04 David Gstir
  2019-05-29 14:18 ` Stephan Mueller
  0 siblings, 1 reply; 5+ messages in thread
From: David Gstir @ 2019-05-29 14:04 UTC (permalink / raw)
  To: Linux Crypto Mailing List; +Cc: linux-kernel, Richard Weinberger

Hi!

I've done some testing with hardware acceleration of hash functions
and noticed that, when using the synchronous message digest API (shash),
some drivers are not usable. In my case the CAAM driver for SHA256.
Using the asynchronous interface (ahash), everything works as expected.
Looking at the driver source, the CAAM driver only implements the ahash
interface. 

I'm wondering if there a way to use an ahash driver through the shash interface?

I've seen that it does actually work the other way around, since 
crypto_init_shash_ops_async() in crypto/shash.c takes care of translating calls
from ahash to shash and that's how the *-generic drivers are usable through the
ahash API.

Thanks!
David

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Can an ahash driver be used through shash API?
  2019-05-29 14:04 Can an ahash driver be used through shash API? David Gstir
@ 2019-05-29 14:18 ` Stephan Mueller
  2019-05-29 20:21   ` Richard Weinberger
  0 siblings, 1 reply; 5+ messages in thread
From: Stephan Mueller @ 2019-05-29 14:18 UTC (permalink / raw)
  To: David Gstir; +Cc: Linux Crypto Mailing List, linux-kernel, Richard Weinberger

Am Mittwoch, 29. Mai 2019, 16:04:47 CEST schrieb David Gstir:

Hi David,

> Hi!
> 
> I've done some testing with hardware acceleration of hash functions
> and noticed that, when using the synchronous message digest API (shash),
> some drivers are not usable. In my case the CAAM driver for SHA256.
> Using the asynchronous interface (ahash), everything works as expected.
> Looking at the driver source, the CAAM driver only implements the ahash
> interface.
> 
> I'm wondering if there a way to use an ahash driver through the shash
> interface?

Short: no.
> 
> I've seen that it does actually work the other way around, since
> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
> calls from ahash to shash and that's how the *-generic drivers are usable
> through the ahash API.

The crypto_alloc_shash will only identify cipher implementations that were 
registered with the CRYPTO_ALG_TYPE_SHASH flag. That flag is set when a cipher 
is registered using crypto_register_shash.

Thus, ciphers registered with crypto_register_ahash will not bear this flag 
and thus will not be found by the allocation function.

Ciao
Stephan



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Can an ahash driver be used through shash API?
  2019-05-29 14:18 ` Stephan Mueller
@ 2019-05-29 20:21   ` Richard Weinberger
  2019-05-30  5:38     ` Stephan Mueller
  2019-05-30 10:02     ` Pascal Van Leeuwen
  0 siblings, 2 replies; 5+ messages in thread
From: Richard Weinberger @ 2019-05-29 20:21 UTC (permalink / raw)
  To: Stephan Mueller; +Cc: david, Linux Crypto Mailing List, linux-kernel

Stephan,

----- Ursprüngliche Mail -----
>> I've seen that it does actually work the other way around, since
>> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
>> calls from ahash to shash and that's how the *-generic drivers are usable
>> through the ahash API.
> 
> The crypto_alloc_shash will only identify cipher implementations that were
> registered with the CRYPTO_ALG_TYPE_SHASH flag. That flag is set when a cipher
> is registered using crypto_register_shash.
> 
> Thus, ciphers registered with crypto_register_ahash will not bear this flag
> and thus will not be found by the allocation function.

is there a reason why we don't emulate the synchronous functionality
in the crypto API layer if a driver implements only the async interface?

Or is it just a matter of -ENOPATCH? :)

Thanks,
//richard

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Can an ahash driver be used through shash API?
  2019-05-29 20:21   ` Richard Weinberger
@ 2019-05-30  5:38     ` Stephan Mueller
  2019-05-30 10:02     ` Pascal Van Leeuwen
  1 sibling, 0 replies; 5+ messages in thread
From: Stephan Mueller @ 2019-05-30  5:38 UTC (permalink / raw)
  To: Richard Weinberger; +Cc: david, Linux Crypto Mailing List, linux-kernel

Am Mittwoch, 29. Mai 2019, 22:21:50 CEST schrieb Richard Weinberger:

Hi Richard,

> Stephan,
> 
> ----- Ursprüngliche Mail -----
> 
> >> I've seen that it does actually work the other way around, since
> >> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
> >> calls from ahash to shash and that's how the *-generic drivers are usable
> >> through the ahash API.
> > 
> > The crypto_alloc_shash will only identify cipher implementations that were
> > registered with the CRYPTO_ALG_TYPE_SHASH flag. That flag is set when a
> > cipher is registered using crypto_register_shash.
> > 
> > Thus, ciphers registered with crypto_register_ahash will not bear this
> > flag
> > and thus will not be found by the allocation function.
> 
> is there a reason why we don't emulate the synchronous functionality
> in the crypto API layer if a driver implements only the async interface?
> 
> Or is it just a matter of -ENOPATCH? :)

How can that be done in the first place? SHASH is intended and is used with 
stack variables. An AHASH will have to be expected to sleep inbetween. Thus, 
it cannot be used as SHASH.

Ciao
Stephan



^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Can an ahash driver be used through shash API?
  2019-05-29 20:21   ` Richard Weinberger
  2019-05-30  5:38     ` Stephan Mueller
@ 2019-05-30 10:02     ` Pascal Van Leeuwen
  1 sibling, 0 replies; 5+ messages in thread
From: Pascal Van Leeuwen @ 2019-05-30 10:02 UTC (permalink / raw)
  To: Richard Weinberger, Stephan Mueller
  Cc: david, Linux Crypto Mailing List, linux-kernel

> >
> > The crypto_alloc_shash will only identify cipher implementations that
> were
> > registered with the CRYPTO_ALG_TYPE_SHASH flag. That flag is set when a
> cipher
> > is registered using crypto_register_shash.
> >
> > Thus, ciphers registered with crypto_register_ahash will not bear this
> flag
> > and thus will not be found by the allocation function.
> 
> is there a reason why we don't emulate the synchronous functionality
> in the crypto API layer if a driver implements only the async interface?
> 
> Or is it just a matter of -ENOPATCH? :)
> 
Well, one reason might be that asynchronous implementations are usually
hardware accelerators that rely on many operations being batch queued in
order to actually usefully accelerate anything (due to large latencies).
Which you can't do from the synchronous interface, so you'd get a slow down, 
not a speed up. 
(But some people - Ad :-) - might argue that using the accelerator may still
be useful to offload the CPU, reduce power consumption, etc.)

In any case, I didn't really know this but I'm quite happy with it. If you
want *performance*, you shouldn't end up at a h/w accelerator with a 
synchronous API. If you do want the h/w acceleration, you can always use
the asynchronous API, so nothing lost there, you do have a choice.

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-05-30 10:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-29 14:04 Can an ahash driver be used through shash API? David Gstir
2019-05-29 14:18 ` Stephan Mueller
2019-05-29 20:21   ` Richard Weinberger
2019-05-30  5:38     ` Stephan Mueller
2019-05-30 10:02     ` Pascal Van Leeuwen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).