Encrypt selftest fails with qat_c3xxx

[Georg Sauthoff]

Hello,

running Fedora 27 on an Intel Atom C3758 CPU Supermicro system
(A2SDi-8C+-HLN4F) I've noticed that crypto selftests fail when the
qat_c3xxx module is loaded (it is loaded, by default). That means that
stuff like `modprobe dm-crypt`, `cryptsetup benchmark` and `cryptsetup
luksOpen` fail.

The kernel log then contains the following messages:

alg: akcipher: encrypt test failed. err -22
alg: akcipher: test 1 failed for pkcs1pad(qat-rsa,sha256), err=-22

When I blacklist the qat_c3xxx/intel_qat modules the crypto works
as expected.

I can reproduce this issue with 4.14.3-300.fc27.x86_64,
kernel-4.13.16-302.fc27.x86_64 and kernel-4.13.9-300.fc27.x86-64.

See also my report in the Fedora bug tracker:

https://bugzilla.redhat.com/show_bug.cgi?id=1522962#c5

The loaded firmware has this checksum:

md5sum /lib/firmware/qat_c3xxx_mmp.bin
fb7deea913d87aed767669a593e6  /lib/firmware/qat_c3xxx_mmp.bin

Is this an issue with the driver, the firmware or does the QAT
co-processor need some additional setup?

Best regards
Georg
-- 
'(EE) Caught signal 11 (Segmentation fault). Server aborting
 (EE) Please also check the log file at "/dev/null" for additional information.'
(Fedora 21, gdm-Xorg)

[PATCH crypto] crypto: aesni - add wrapper for generic gcm(aes)

[Sabrina Dubroca]

When I added generic-gcm-aes I didn't add a wrapper like the one
provided for rfc4106(gcm(aes)). We need to add a cryptd wrapper to fall
back on in case the FPU is not available, otherwise we might corrupt the
FPU state.

Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
Reported-by: Ilya Lesokhin 
Signed-off-by: Sabrina Dubroca 
Reviewed-by: Stefano Brivio 
---
 arch/x86/crypto/aesni-intel_glue.c | 66 +++---
 1 file changed, 54 insertions(+), 12 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
index 8981ed1eb7ad..a5ee78d723cd 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -690,8 +690,8 @@ static int common_rfc4106_set_key(struct crypto_aead *aead, 
const u8 *key,
   rfc4106_set_hash_subkey(ctx->hash_subkey, key, key_len);
 }
 
-static int rfc4106_set_key(struct crypto_aead *parent, const u8 *key,
-  unsigned int key_len)
+static int gcmaes_wrapper_set_key(struct crypto_aead *parent, const u8 *key,
+ unsigned int key_len)
 {
struct cryptd_aead **ctx = crypto_aead_ctx(parent);
struct cryptd_aead *cryptd_tfm = *ctx;
@@ -716,8 +716,8 @@ static int common_rfc4106_set_authsize(struct crypto_aead 
*aead,
 
 /* This is the Integrity Check Value (aka the authentication tag length and can
  * be 8, 12 or 16 bytes long. */
-static int rfc4106_set_authsize(struct crypto_aead *parent,
-   unsigned int authsize)
+static int gcmaes_wrapper_set_authsize(struct crypto_aead *parent,
+  unsigned int authsize)
 {
struct cryptd_aead **ctx = crypto_aead_ctx(parent);
struct cryptd_aead *cryptd_tfm = *ctx;
@@ -929,7 +929,7 @@ static int helper_rfc4106_decrypt(struct aead_request *req)
  aes_ctx);
 }
 
-static int rfc4106_encrypt(struct aead_request *req)
+static int gcmaes_wrapper_encrypt(struct aead_request *req)
 {
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct cryptd_aead **ctx = crypto_aead_ctx(tfm);
@@ -945,7 +945,7 @@ static int rfc4106_encrypt(struct aead_request *req)
return crypto_aead_encrypt(req);
 }
 
-static int rfc4106_decrypt(struct aead_request *req)
+static int gcmaes_wrapper_decrypt(struct aead_request *req)
 {
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct cryptd_aead **ctx = crypto_aead_ctx(tfm);
@@ -1128,6 +1128,30 @@ static int generic_gcmaes_decrypt(struct aead_request 
*req)
  aes_ctx);
 }
 
+static int generic_gcmaes_init(struct crypto_aead *aead)
+{
+   struct cryptd_aead *cryptd_tfm;
+   struct cryptd_aead **ctx = crypto_aead_ctx(aead);
+
+   cryptd_tfm = cryptd_alloc_aead("__driver-generic-gcm-aes-aesni",
+  CRYPTO_ALG_INTERNAL,
+  CRYPTO_ALG_INTERNAL);
+   if (IS_ERR(cryptd_tfm))
+   return PTR_ERR(cryptd_tfm);
+
+   *ctx = cryptd_tfm;
+   crypto_aead_set_reqsize(aead, crypto_aead_reqsize(_tfm->base));
+
+   return 0;
+}
+
+static void generic_gcmaes_exit(struct crypto_aead *aead)
+{
+   struct cryptd_aead **ctx = crypto_aead_ctx(aead);
+
+   cryptd_free_aead(*ctx);
+}
+
 static struct aead_alg aesni_aead_algs[] = { {
.setkey = common_rfc4106_set_key,
.setauthsize= common_rfc4106_set_authsize,
@@ -1147,10 +1171,10 @@ static struct aead_alg aesni_aead_algs[] = { {
 }, {
.init   = rfc4106_init,
.exit   = rfc4106_exit,
-   .setkey = rfc4106_set_key,
-   .setauthsize= rfc4106_set_authsize,
-   .encrypt= rfc4106_encrypt,
-   .decrypt= rfc4106_decrypt,
+   .setkey = gcmaes_wrapper_set_key,
+   .setauthsize= gcmaes_wrapper_set_authsize,
+   .encrypt= gcmaes_wrapper_encrypt,
+   .decrypt= gcmaes_wrapper_decrypt,
.ivsize = GCM_RFC4106_IV_SIZE,
.maxauthsize= 16,
.base = {
@@ -1169,14 +1193,32 @@ static struct aead_alg aesni_aead_algs[] = { {
.decrypt= generic_gcmaes_decrypt,
.ivsize = GCM_AES_IV_SIZE,
.maxauthsize= 16,
+   .base = {
+   .cra_name   = "__generic-gcm-aes-aesni",
+   .cra_driver_name= "__driver-generic-gcm-aes-aesni",
+   .cra_priority   = 0,
+   .cra_flags  = CRYPTO_ALG_INTERNAL,
+   .cra_blocksize  = 1,
+   .cra_ctxsize= sizeof(struct generic_gcmaes_ctx),
+   .cra_alignmask  = AESNI_ALIGN - 

[PATCH crypto] crypto: aesni - fix typo in generic_gcmaes_decrypt

[Sabrina Dubroca]

generic_gcmaes_decrypt needs to use generic_gcmaes_ctx, not
aesni_rfc4106_gcm_ctx. This is actually harmless because the fields in
struct generic_gcmaes_ctx share the layout of the same fields in
aesni_rfc4106_gcm_ctx.

Fixes: cce2ea8d90fe ("crypto: aesni - add generic gcm(aes)")
Signed-off-by: Sabrina Dubroca 
Reviewed-by: Stefano Brivio 
---
 arch/x86/crypto/aesni-intel_glue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c 
b/arch/x86/crypto/aesni-intel_glue.c
index 3bf3dcf29825..8981ed1eb7ad 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1117,7 +1117,7 @@ static int generic_gcmaes_decrypt(struct aead_request 
*req)
 {
__be32 counter = cpu_to_be32(1);
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
-   struct aesni_rfc4106_gcm_ctx *ctx = aesni_rfc4106_gcm_ctx_get(tfm);
+   struct generic_gcmaes_ctx *ctx = generic_gcmaes_ctx_get(tfm);
void *aes_ctx = &(ctx->aes_key_expanded);
u8 iv[16] __attribute__ ((__aligned__(AESNI_ALIGN)));
 
-- 
2.15.1

Re: [PATCH 6/6] crypto: tcrypt: add multibuf aead speed test

[Gilad Ben-Yossef]

On Wed, Dec 13, 2017 at 2:31 PM, Herbert Xu  wrote:
> On Wed, Dec 13, 2017 at 11:12:10AM +0200, Gilad Ben-Yossef wrote:
>>
>> I'm sorry if I'm confused but as the cover letter stated, the patch
>> set is supposed to
>> go on top of the patch entitled  "crypto: tcrypt - fix S/G table for
>> test_aead_speed()"
>> which you stated will be applied
>> (https://patchwork.kernel.org/patch/9995727/) but
>> is not in the tree yet.
>
> It is in cryptodev as
>
> commit 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1
> Author: Robert Baronescu 
> Date:   Tue Oct 10 13:21:59 2017 +0300
>
> crypto: tcrypt - fix S/G table for test_aead_speed()
>
> Yet your patch still fails to apply.

Opps sorry. I've accidentally checked against crypto and not cryptodev
My bad.

Will respin. Sorry for the noise.

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

Re: [PATCH 6/6] crypto: tcrypt: add multibuf aead speed test

[Herbert Xu]

On Wed, Dec 13, 2017 at 11:12:10AM +0200, Gilad Ben-Yossef wrote:
> 
> I'm sorry if I'm confused but as the cover letter stated, the patch
> set is supposed to
> go on top of the patch entitled  "crypto: tcrypt - fix S/G table for
> test_aead_speed()"
> which you stated will be applied
> (https://patchwork.kernel.org/patch/9995727/) but
> is not in the tree yet.

It is in cryptodev as

commit 5c6ac1d4f8fbdbed65dbeb8cf149d736409d16a1
Author: Robert Baronescu 
Date:   Tue Oct 10 13:21:59 2017 +0300

crypto: tcrypt - fix S/G table for test_aead_speed()

Yet your patch still fails to apply.

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

Re: [PATCH 6/6] crypto: tcrypt: add multibuf aead speed test

[Gilad Ben-Yossef]

Hi Herbert,

On Mon, Dec 11, 2017 at 1:35 PM, Herbert Xu  wrote:
> On Thu, Nov 30, 2017 at 10:09:32AM +, Gilad Ben-Yossef wrote:
>> The performance of some aead tfm providers is affected by
>> the amount of parallelism possible with the processing.
>>
>> Introduce an async aead concurrent multiple buffer
>> processing speed test to be able to test performance of such
>> tfm providers.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
> Sorry, this no longer applies to the current cryptodev tree.
>
> Please respin.
>

I'm sorry if I'm confused but as the cover letter stated, the patch
set is supposed to
go on top of the patch entitled  "crypto: tcrypt - fix S/G table for
test_aead_speed()"
which you stated will be applied
(https://patchwork.kernel.org/patch/9995727/) but
is not in the tree yet.

Apart from touching the same code that fix is needed because without it all the
AEAD speed tests crash so it's impossible to test my own additions.

If you apply Robert's patch to cryptodev my own patch set applies on
top of it OK.

Did I miss something?

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

Re: [PATCH v3 3/4] crypto: exynos - Reseed PRNG after generating 2^16 random bytes

[Krzysztof Kozlowski]

On Tue, Dec 12, 2017 at 5:36 PM, Łukasz Stelmach  wrote:
> Reseed PRNG after reading 65 kB of randomness. Although this may reduce
> performance, in most cases the loss is not noticeable. Also the time
> based threshold for reseeding is changed to one second. Reseeding is
> performed whenever either limit is exceeded.
>
> Reseeding of a PRNG does not increase entropy, but it helps preventing
> backtracking the internal state of the device from its output sequence,
> and hence, prevents potential attacker from predicting numbers to be
> generated.
>
> Signed-off-by: Łukasz Stelmach 
> Reviewed-by: Stephan Mueller 
> ---
>  drivers/crypto/exynos-rng.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v3 2/4] crypto: exynos - Improve performance of PRNG

[Krzysztof Kozlowski]

On Tue, Dec 12, 2017 at 5:36 PM, Łukasz Stelmach  wrote:
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.

If I recall correctly, you mentioned before that it improves the
performance. If so it would be nice to mention some numbers here.

Anyway it is fine with me:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

>
> Signed-off-by: Łukasz Stelmach 
> ---
>  drivers/crypto/exynos-rng.c | 31 ++-
>  1 file changed, 2 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/crypto/exynos-rng.c b/drivers/crypto/exynos-rng.c
> index 825c09619eb8..dcdd444d0b3b 100644
> --- a/drivers/crypto/exynos-rng.c
> +++ b/drivers/crypto/exynos-rng.c
> @@ -131,34 +131,6 @@ static int exynos_rng_set_seed(struct exynos_rng_dev 
> *rng,
>  }
>
>  /*
> - * Read from output registers and put the data under 'dst' array,
> - * up to dlen bytes.
> - *
> - * Returns number of bytes actually stored in 'dst' (dlen
> - * or EXYNOS_RNG_SEED_SIZE).
> - */
> -static unsigned int exynos_rng_copy_random(struct exynos_rng_dev *rng,
> -  u8 *dst, unsigned int dlen)
> -{
> -   unsigned int cnt = 0;
> -   int i, j;
> -   u32 val;
> -
> -   for (j = 0; j < EXYNOS_RNG_SEED_REGS; j++) {
> -   val = exynos_rng_readl(rng, EXYNOS_RNG_OUT(j));
> -
> -   for (i = 0; i < 4; i++) {
> -   dst[cnt] = val & 0xff;
> -   val >>= 8;
> -   if (++cnt >= dlen)
> -   return cnt;
> -   }
> -   }
> -
> -   return cnt;
> -}
> -
> -/*
>   * Start the engine and poll for finish.  Then read from output registers
>   * filling the 'dst' buffer up to 'dlen' bytes or up to size of generated
>   * random data (EXYNOS_RNG_SEED_SIZE).
> @@ -190,7 +162,8 @@ static int exynos_rng_get_random(struct exynos_rng_dev 
> *rng,
> /* Clear status bit */
> exynos_rng_writel(rng, EXYNOS_RNG_STATUS_RNG_DONE,
>   EXYNOS_RNG_STATUS);
> -   *read = exynos_rng_copy_random(rng, dst, dlen);
> +   *read = min_t(size_t, dlen, EXYNOS_RNG_SEED_SIZE);
> +   memcpy_fromio(dst, rng->mem + EXYNOS_RNG_OUT_BASE, *read);
>
> return 0;
>  }
> --
> 2.11.0
>

Re: [PATCH v3 1/4] crypto: exynos - Support Exynos5250+ SoCs

[Krzysztof Kozlowski]

On Tue, Dec 12, 2017 at 5:36 PM, Łukasz Stelmach  wrote:
> Add support for PRNG in Exynos5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach 
> ---
>  .../bindings/crypto/samsung,exynos-rng4.txt|  4 +++-
>  drivers/crypto/exynos-rng.c| 27 
> --
>  2 files changed, 28 insertions(+), 3 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof