This module provides implementations for "des3_ede", too. Announce those
via an appropriate crypto module alias so it can be used in favour to
the generic C implementation.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
We tried linking in a single built object to hold the device table,
but only works if all of the sparc64 crypto modules get built the same
way (modular vs. non-modular).
Just include the device ID stub into each driver source file so that
the table gets compiled into the correct result in all cases.
Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Make the crypto opcode implementations have a higher priority than
those provides by the ring buffer based Niagara crypto device.
Also, several crypto opcode hashes were not setting the priority value
at all.
Signed-off-by: David S. Miller <davem@davemloft.net>
Mathias Krause