Discussion:
3.17 regression; alg: skcipher: Chunk test 1 failed on encryption at page 0 for ecb-aes-padlock
Ard Biesheuvel
2014-10-20 07:59:26 UTC
Permalink
I get this new failure w/3.17.0 on my system with a VIA Esther
alg: skcipher: Chunk test 1 failed on encryption at page 0 for ecb-aes-padlock
00000000: 71 73 f7 db 24 93 21 6d 61 1e bb 63 42 79 db 64
00000010: 6f 82 c0 ca a3 9b fa 0b d9 08 c7 4a 90 ae 8f 5f
00000020: 5e 06 f0 5f 31 51 18 37 45 d7 ca 3a fd 6c 3f e1
00000030: dd 8d 22 65 2b 00 50 ce ba 28 67 d7 ce 0e 0d ea
00000040: 78 69 7f ae 8f 8b 69 37 75 e0 dc 96 e0 b7 f4 09
00000050: cb 6d a2 fb da af 09 f8 81 82 27 fa 45 9c 29 a4
00000060: 22 8b 78 69 5b 46 f9 39 1b cc f9 1d 09 eb bc 5c
00000070: 41 72 51 97 1d 07 49 a0 1b 8e 65 4b b2 6a 12 03
00000080: 6a 60 95 ac bd ac 1a 64 de 5a a5 f0 83 2f cb ca
00000090: 22 74 a6 6c 9b 73 ce 3f e1 8b 22 17 59 0c 47 89
000000a0: 33 a1 d6 47 03 19 4f a8 67 69 f0 5b f0 20 ad 06
000000b0: 27 81 92 d8 c5 ba 98 12 be 24 b5 2f 75 02 c2 ad
000000c0: 12 2f 07 32 ee 39 af 64 05 8f b3 d4 eb 1b 46 6e
000000d0: d9 21 f9 c4 b7 c9 45 68 b4 a1 74 9f 82 47 eb cc
000000e0: bd 0a 14 95 0f 8b a8 2f 4b 1b a7 bf 82 a6 43 0c
000000f0: b9 39 4a a8 10 6f 50 7b 25 fb 26 81 e0 2f f0 96
00000100: 8d 8b ac 92 0f f6 ed 64 63 29 4c 8e 18 13 c5 bf
00000110: fc a0 d9 bf 7c 3a 0e 29 6f d1 6c 6f a5 da bf b1
00000120: 30 ea 44 2d c3 8f 16 e1 66 fa a3 21 3e fc 13 ca
00000130: f0 f6 f0 59 bd 8f 38 50 31 cb 69 3f 96 15 d6 f5
00000140: ae ff f6 aa 41 85 4c 10 58 e3 f9 44 e6 28 da 9a
00000150: dc 6a 80 34 73 97 1b c5 ca 26 16 77 0e 60 ab 89
00000160: 0f 04 27 bd ce 3e 71 b4 a0 d7 22 7e db eb 24 70
00000170: 42 71 51 78 70 b3 e0 3d 84 8e 8d 7b d0 6d ea 92
00000180: 11 08 42 4f e5 ad 26 92 d2 00 ae a8 e3 4b 37 47
00000190: 22 c1 95 c1 63 7f cb 03 f3 e3 d7 9d 60 c7 bc ea
000001a0: 35 a2 fd 45 52 39 13 6f c1 53 f3 53 df 33 84 d7
000001b0: d2 c8 37 b0 75 e3 41 46 b3 c7 83 2e 8a bb a4 e5
000001c0: 7f 3c fd 8b eb ea 63 bd b7 46 e7 bf 09 9c 0d 0f
000001d0: 33 84 aa 1c 8d 29 b4 ac 4f ad e6 89
I've bisected this to 3b9b8fe0ade1ee84ee4058261d2e39a1f283704b so ...
perhaps intended in terms of uncovering problems. Seems to have
identified something in my case at any rate.
Attached is my full 3.17.0 dmesg, kernel config, and /proc/crypto contents
(the only difference between 3.16 and 3.17 for the latter being the
selftest value for ecb-aes-padlock which used to be "passed" with 3.16
and earlier.)
Let me know if you need anything else.
Interesting. I don't have access to the hardware, but I found
something interesting in the driver related to the prefetch size
(ecb_fetch_bytes) of ECB versus CBC (Note that the CBC selftest
passes)
So perhaps this might solve the bug, could you please test it?

diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 633ba945e153..2834f0b23713 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -351,7 +351,7 @@ static int ecb_aes_encrypt(struct blkcipher_desc *desc,
padlock_reset_key(&ctx->cword.encrypt);

blkcipher_walk_init(&walk, dst, src, nbytes);
- err = blkcipher_walk_virt(desc, &walk);
+ err = blkcipher_walk_virt_block(desc, &walk, ecb_fetch_bytes);

ts_state = irq_ts_save();
while ((nbytes = walk.nbytes)) {
@@ -380,7 +380,7 @@ static int ecb_aes_decrypt(struct blkcipher_desc *desc,
padlock_reset_key(&ctx->cword.decrypt);

blkcipher_walk_init(&walk, dst, src, nbytes);
- err = blkcipher_walk_virt(desc, &walk);
+ err = blkcipher_walk_virt_block(desc, &walk, ecb_fetch_bytes);

ts_state = irq_ts_save();
while ((nbytes = walk.nbytes)) {

It will basically instruct the crypto layer not to pass fewer than 2
blocks at a time until there is really no other way, i.e., until the
input is exhausted.
--
Ard.
Jamie Heilman
2014-10-20 23:43:33 UTC
Permalink
Post by Ard Biesheuvel
I get this new failure w/3.17.0 on my system with a VIA Esther
alg: skcipher: Chunk test 1 failed on encryption at page 0 for ecb-aes-padlock
00000000: 71 73 f7 db 24 93 21 6d 61 1e bb 63 42 79 db 64
00000010: 6f 82 c0 ca a3 9b fa 0b d9 08 c7 4a 90 ae 8f 5f
00000020: 5e 06 f0 5f 31 51 18 37 45 d7 ca 3a fd 6c 3f e1
00000030: dd 8d 22 65 2b 00 50 ce ba 28 67 d7 ce 0e 0d ea
00000040: 78 69 7f ae 8f 8b 69 37 75 e0 dc 96 e0 b7 f4 09
00000050: cb 6d a2 fb da af 09 f8 81 82 27 fa 45 9c 29 a4
00000060: 22 8b 78 69 5b 46 f9 39 1b cc f9 1d 09 eb bc 5c
00000070: 41 72 51 97 1d 07 49 a0 1b 8e 65 4b b2 6a 12 03
00000080: 6a 60 95 ac bd ac 1a 64 de 5a a5 f0 83 2f cb ca
00000090: 22 74 a6 6c 9b 73 ce 3f e1 8b 22 17 59 0c 47 89
000000a0: 33 a1 d6 47 03 19 4f a8 67 69 f0 5b f0 20 ad 06
000000b0: 27 81 92 d8 c5 ba 98 12 be 24 b5 2f 75 02 c2 ad
000000c0: 12 2f 07 32 ee 39 af 64 05 8f b3 d4 eb 1b 46 6e
000000d0: d9 21 f9 c4 b7 c9 45 68 b4 a1 74 9f 82 47 eb cc
000000e0: bd 0a 14 95 0f 8b a8 2f 4b 1b a7 bf 82 a6 43 0c
000000f0: b9 39 4a a8 10 6f 50 7b 25 fb 26 81 e0 2f f0 96
00000100: 8d 8b ac 92 0f f6 ed 64 63 29 4c 8e 18 13 c5 bf
00000110: fc a0 d9 bf 7c 3a 0e 29 6f d1 6c 6f a5 da bf b1
00000120: 30 ea 44 2d c3 8f 16 e1 66 fa a3 21 3e fc 13 ca
00000130: f0 f6 f0 59 bd 8f 38 50 31 cb 69 3f 96 15 d6 f5
00000140: ae ff f6 aa 41 85 4c 10 58 e3 f9 44 e6 28 da 9a
00000150: dc 6a 80 34 73 97 1b c5 ca 26 16 77 0e 60 ab 89
00000160: 0f 04 27 bd ce 3e 71 b4 a0 d7 22 7e db eb 24 70
00000170: 42 71 51 78 70 b3 e0 3d 84 8e 8d 7b d0 6d ea 92
00000180: 11 08 42 4f e5 ad 26 92 d2 00 ae a8 e3 4b 37 47
00000190: 22 c1 95 c1 63 7f cb 03 f3 e3 d7 9d 60 c7 bc ea
000001a0: 35 a2 fd 45 52 39 13 6f c1 53 f3 53 df 33 84 d7
000001b0: d2 c8 37 b0 75 e3 41 46 b3 c7 83 2e 8a bb a4 e5
000001c0: 7f 3c fd 8b eb ea 63 bd b7 46 e7 bf 09 9c 0d 0f
000001d0: 33 84 aa 1c 8d 29 b4 ac 4f ad e6 89
I've bisected this to 3b9b8fe0ade1ee84ee4058261d2e39a1f283704b so ...
perhaps intended in terms of uncovering problems. Seems to have
identified something in my case at any rate.
Attached is my full 3.17.0 dmesg, kernel config, and /proc/crypto contents
(the only difference between 3.16 and 3.17 for the latter being the
selftest value for ecb-aes-padlock which used to be "passed" with 3.16
and earlier.)
Let me know if you need anything else.
Interesting. I don't have access to the hardware, but I found
something interesting in the driver related to the prefetch size
(ecb_fetch_bytes) of ECB versus CBC (Note that the CBC selftest
passes)
So perhaps this might solve the bug, could you please test it?
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 633ba945e153..2834f0b23713 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -351,7 +351,7 @@ static int ecb_aes_encrypt(struct blkcipher_desc *desc,
padlock_reset_key(&ctx->cword.encrypt);
blkcipher_walk_init(&walk, dst, src, nbytes);
- err = blkcipher_walk_virt(desc, &walk);
+ err = blkcipher_walk_virt_block(desc, &walk, ecb_fetch_bytes);
ts_state = irq_ts_save();
while ((nbytes = walk.nbytes)) {
@@ -380,7 +380,7 @@ static int ecb_aes_decrypt(struct blkcipher_desc *desc,
padlock_reset_key(&ctx->cword.decrypt);
blkcipher_walk_init(&walk, dst, src, nbytes);
- err = blkcipher_walk_virt(desc, &walk);
+ err = blkcipher_walk_virt_block(desc, &walk, ecb_fetch_bytes);
ts_state = irq_ts_save();
while ((nbytes = walk.nbytes)) {
It will basically instruct the crypto layer not to pass fewer than 2
blocks at a time until there is really no other way, i.e., until the
input is exhausted.
Nope. Test still fails w/exactly the same output as before.
--
Jamie Heilman http://audible.transient.net/~jamie/
Ard Biesheuvel
2014-10-21 06:03:59 UTC
Permalink
Post by Jamie Heilman
Post by Ard Biesheuvel
I get this new failure w/3.17.0 on my system with a VIA Esther
alg: skcipher: Chunk test 1 failed on encryption at page 0 for ecb-aes-padlock
00000000: 71 73 f7 db 24 93 21 6d 61 1e bb 63 42 79 db 64
00000010: 6f 82 c0 ca a3 9b fa 0b d9 08 c7 4a 90 ae 8f 5f
00000020: 5e 06 f0 5f 31 51 18 37 45 d7 ca 3a fd 6c 3f e1
00000030: dd 8d 22 65 2b 00 50 ce ba 28 67 d7 ce 0e 0d ea
00000040: 78 69 7f ae 8f 8b 69 37 75 e0 dc 96 e0 b7 f4 09
00000050: cb 6d a2 fb da af 09 f8 81 82 27 fa 45 9c 29 a4
00000060: 22 8b 78 69 5b 46 f9 39 1b cc f9 1d 09 eb bc 5c
00000070: 41 72 51 97 1d 07 49 a0 1b 8e 65 4b b2 6a 12 03
00000080: 6a 60 95 ac bd ac 1a 64 de 5a a5 f0 83 2f cb ca
00000090: 22 74 a6 6c 9b 73 ce 3f e1 8b 22 17 59 0c 47 89
000000a0: 33 a1 d6 47 03 19 4f a8 67 69 f0 5b f0 20 ad 06
000000b0: 27 81 92 d8 c5 ba 98 12 be 24 b5 2f 75 02 c2 ad
000000c0: 12 2f 07 32 ee 39 af 64 05 8f b3 d4 eb 1b 46 6e
000000d0: d9 21 f9 c4 b7 c9 45 68 b4 a1 74 9f 82 47 eb cc
000000e0: bd 0a 14 95 0f 8b a8 2f 4b 1b a7 bf 82 a6 43 0c
000000f0: b9 39 4a a8 10 6f 50 7b 25 fb 26 81 e0 2f f0 96
00000100: 8d 8b ac 92 0f f6 ed 64 63 29 4c 8e 18 13 c5 bf
00000110: fc a0 d9 bf 7c 3a 0e 29 6f d1 6c 6f a5 da bf b1
00000120: 30 ea 44 2d c3 8f 16 e1 66 fa a3 21 3e fc 13 ca
00000130: f0 f6 f0 59 bd 8f 38 50 31 cb 69 3f 96 15 d6 f5
00000140: ae ff f6 aa 41 85 4c 10 58 e3 f9 44 e6 28 da 9a
00000150: dc 6a 80 34 73 97 1b c5 ca 26 16 77 0e 60 ab 89
00000160: 0f 04 27 bd ce 3e 71 b4 a0 d7 22 7e db eb 24 70
00000170: 42 71 51 78 70 b3 e0 3d 84 8e 8d 7b d0 6d ea 92
00000180: 11 08 42 4f e5 ad 26 92 d2 00 ae a8 e3 4b 37 47
00000190: 22 c1 95 c1 63 7f cb 03 f3 e3 d7 9d 60 c7 bc ea
000001a0: 35 a2 fd 45 52 39 13 6f c1 53 f3 53 df 33 84 d7
000001b0: d2 c8 37 b0 75 e3 41 46 b3 c7 83 2e 8a bb a4 e5
000001c0: 7f 3c fd 8b eb ea 63 bd b7 46 e7 bf 09 9c 0d 0f
000001d0: 33 84 aa 1c 8d 29 b4 ac 4f ad e6 89
I've bisected this to 3b9b8fe0ade1ee84ee4058261d2e39a1f283704b so ...
perhaps intended in terms of uncovering problems. Seems to have
identified something in my case at any rate.
Attached is my full 3.17.0 dmesg, kernel config, and /proc/crypto contents
(the only difference between 3.16 and 3.17 for the latter being the
selftest value for ecb-aes-padlock which used to be "passed" with 3.16
and earlier.)
Let me know if you need anything else.
Interesting. I don't have access to the hardware, but I found
something interesting in the driver related to the prefetch size
(ecb_fetch_bytes) of ECB versus CBC (Note that the CBC selftest
passes)
So perhaps this might solve the bug, could you please test it?
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 633ba945e153..2834f0b23713 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -351,7 +351,7 @@ static int ecb_aes_encrypt(struct blkcipher_desc *desc,
padlock_reset_key(&ctx->cword.encrypt);
blkcipher_walk_init(&walk, dst, src, nbytes);
- err = blkcipher_walk_virt(desc, &walk);
+ err = blkcipher_walk_virt_block(desc, &walk, ecb_fetch_bytes);
ts_state = irq_ts_save();
while ((nbytes = walk.nbytes)) {
@@ -380,7 +380,7 @@ static int ecb_aes_decrypt(struct blkcipher_desc *desc,
padlock_reset_key(&ctx->cword.decrypt);
blkcipher_walk_init(&walk, dst, src, nbytes);
- err = blkcipher_walk_virt(desc, &walk);
+ err = blkcipher_walk_virt_block(desc, &walk, ecb_fetch_bytes);
ts_state = irq_ts_save();
while ((nbytes = walk.nbytes)) {
It will basically instruct the crypto layer not to pass fewer than 2
blocks at a time until there is really no other way, i.e., until the
input is exhausted.
Nope. Test still fails w/exactly the same output as before.
OK, thanks for trying. I am going to let those with access with the
hardware take over now ...
--
Ard.
Loading...