2009-02-05 10:55:39

by Geert Uytterhoeven

[permalink] [raw]
Subject: LRW endian issues?

When running "modprobe tcrypt mode=10" on ppc64 (PS3), I get the following
error:

| alg: skcipher: Test 8 failed on encryption for lrw(aes-generic)
| 00000000: 1a 1d a9 30 ad f9 2f 9b b6 1d ae ef f0 2f f8 5a
| 00000010: 3d de 22 4d 7e b1 75 e0 d2 db 9e ba 64 b2 5d 93
| 00000020: 4d 14 3d b8 5b 80 9d 57 2e 64 c7 95 d8 b5 a7 3b
| 00000030: 3d 39 8a 9b 59 1c 73 12 2f 58 00 6f 28 3f 72 23
| 00000040: ad 75 cd c0 17 2b bf 62 d2 b2 f9 b7 3f de 3e 83
| 00000050: f2 fa e2 3a e3 03 14 84 3b 47 0e 94 ad 7f e0 dc
| 00000060: 13 c7 56 75 3c 8f 38 88 dd 7f b7 44 b9 30 aa f6
| 00000070: 61 dc b7 4d 72 7e 43 3e 19 a9 fb 1b d4 18 d6 1c
| 00000080: 1d 73 9b 47 7a c9 c7 4b 30 2a 12 4f d7 1e eb bc
| 00000090: e3 13 5b 1c f0 41 33 ae f8 81 a4 54 42 d0 fc 6c
| 000000a0: 65 c5 b2 d8 96 43 ba 11 8d 89 a7 4d 75 e4 3e 07
| 000000b0: 82 11 74 47 70 ff 37 5d 03 ef ec 1d 43 9b 28 10
| 000000c0: ea 67 4e f9 10 9a f4 70 36 e6 af db cb 05 22 54
| 000000d0: 56 41 fa 15 01 c3 ed ce 2f 15 35 df 0e fc 88 bc
| 000000e0: c1 a9 df 2e 25 74 64 5a 21 81 e7 7d 43 ea 85 fc
| 000000f0: 50 d2 5c e6 70 be 56 8a dc cb d1 c3 98 e5 d8 0d
| 00000100: c5 93 2a 30 b7 0e 29 44 6a a4 ca 64 f8 a8 21 6a
| 00000110: 48 8e fc 5f e7 d7 d3 73 20 e6 fe 97 cd d4 33 2e
| 00000120: 0c 57 0c 55 15 e4 4e 62 cf 6a 0a 5f b0 c0 2e da
| 00000130: 86 f8 97 7b 8c ba fc 28 11 29 60 a1 84 0e 4d be
| 00000140: 75 04 45 8d 9b 43 e9 69 e3 46 87 8d 4c c9 c9 e8
| 00000150: cf 35 82 38 c8 91 13 db cd 4e 8f 39 13 0f fd c9
| 00000160: 70 73 d2 8d e3 1b 2b 3b 1d b2 bc 53 bc 05 ca 69
| 00000170: ee c7 62 77 4e 40 d2 88 7e 1b 81 54 38 9d 98 f1
| 00000180: ef cb dd 4b 14 50 fe 57 0a 2c 5c ed 27 a8 de e3
| 00000190: 73 c1 55 d3 43 1a f0 98 54 7c 82 9f 7b fa 48 5c
| 000001a0: b5 b9 90 e2 62 f4 5d 3d 28 34 34 52 47 58 9d ec
| 000001b0: d3 82 07 aa 75 c1 7e f5 03 1f 7f 4b 89 ac a9 89
| 000001c0: 3c 91 85 7e 5f 70 00 20 55 aa 31 84 3c a9 d2 44
| 000001d0: 88 da 71 71 d8 e0 c3 86 c6 6e c2 5e cb 5a 6c fc
| 000001e0: a7 52 0d bf 42 0e c2 fa 9f 59 a6 9b ca 4d fa 50
| 000001f0: 02 fa 55 94 a7 d0 5b 68 3c 35 49 0f 49 d4 3d b4

and the modprobe hangs.

I also tried on ppc32 and m68k, where I got similar results (the first line is
identical to the ppc64 case, the others aren't):

| alg: skcipher: Test 8 failed on encryption for lrw(aes-generic)
| 00000000: 1a 1d a9 30 ad f9 2f 9b b6 1d ae ef f0 2f f8 5a
| 00000010: bd 65 86 e6 dd 79 e0 2a d4 0c c3 9d 03 fd e5 eb
| 00000020: 3f 8e 52 4e ea b4 f5 a9 d3 7f 96 88 4d ea ab db
| 00000030: 7e ae b4 ac ba ea 06 88 40 55 28 3e 6c 65 12 08
| 00000040: fe 6d 1b 5e b3 ba 88 95 f5 f1 ba 74 12 c7 59 bd
| 00000050: 59 66 bc 71 2c 72 82 36 03 45 e9 1f cd 39 a0 a8
| 00000060: a3 44 6e 4b e8 80 c7 ec d3 5d 21 37 1d e6 ca 43
| 00000070: 66 a0 32 e7 fc a5 8f e7 83 bc 71 47 78 3b 50 bf
| 00000080: 92 74 53 44 ac de b4 16 45 87 45 f4 43 8a 19 0e
| 00000090: 4b 7a b6 f1 d9 5e 22 82 4c 0e b7 82 ac 8e 9c 88
| 000000a0: d4 3b 7e 5d 9a eb 71 fa 21 11 88 79 51 56 05 c3
| 000000b0: af 3a 45 8a 00 d1 96 77 59 04 90 cb d4 fc 2a 35
| 000000c0: e7 47 00 83 fd 9c 88 0c 0b 89 3e 69 e3 63 d0 73
| 000000d0: 70 b3 71 21 9f 22 dd 20 3c 2a 9a 3a 03 3b d2 22
| 000000e0: fc 35 68 d4 99 b6 01 41 48 cf 3c a5 86 83 06 0d
| 000000f0: 49 8f 41 ed fa 43 42 e9 37 81 58 4e 18 bf fc d2
| 00000100: 06 c1 73 1e 92 0d 73 c6 86 a6 73 9f 97 5a 62 10
| 00000110: 18 0a ce 5c 58 66 4d 4d c8 25 6d fe c9 b7 ca e3
| 00000120: 4c 29 d7 9d bc 7a 8b 61 29 82 8f 4c 3e 80 61 13
| 00000130: 85 2c 5b 9c 78 ec 8e d6 1f 66 85 b5 2f 74 bd cd
| 00000140: 5a 5d 1f 17 b5 e5 ae 12 d8 3e 3a bc 28 a3 b2 77
| 00000150: 3c 4b 7a f8 bd 1a d3 5f 73 3e 84 df 3a a7 0b 30
| 00000160: 4e 82 34 e8 64 a0 cf 29 b6 de da 39 69 1c 59 91
| 00000170: 0d c7 ec 79 83 1b 25 1f f9 2d e8 ff d5 07 00 16
| 00000180: de 61 f3 a5 2a ed 95 96 31 4d da 2c f9 c4 84 4b
| 00000190: 44 47 da 1a 97 17 f1 01 cd 3e 55 69 89 99 50 9a
| 000001a0: d8 5c 6f 53 ad 07 89 22 6e 78 42 c3 84 3a 01 b9
| 000001b0: a8 05 4a f6 b6 d5 d9 f5 38 96 cf 45 53 42 ac 63
| 000001c0: 17 f2 59 7a 46 a4 04 68 c1 a7 7a de 59 65 44 7b
| 000001d0: 29 b2 d0 75 17 8b f2 f9 22 ef 13 48 7d 17 d6 23
| 000001e0: 91 f3 2e aa e5 2f df e6 f4 84 8a b7 0a 0c 0b c1
| 000001f0: 0b 72 75 de 9a b9 ec e2 05 2c 87 0c ca 7e a8 a8

On x86-32 (User-Mode-Linux) it works fine, so this looks like an endian issue.

I'm using 2.6.29-rc3+.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium

Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010


2009-02-06 04:01:31

by Herbert Xu

[permalink] [raw]
Subject: Re: LRW endian issues?

Geert Uytterhoeven <[email protected]> wrote:
> When running "modprobe tcrypt mode=10" on ppc64 (PS3), I get the following
> error:
>
> | alg: skcipher: Test 8 failed on encryption for lrw(aes-generic)
> | 00000000: 1a 1d a9 30 ad f9 2f 9b b6 1d ae ef f0 2f f8 5a
> | 00000010: 3d de 22 4d 7e b1 75 e0 d2 db 9e ba 64 b2 5d 93
> | 00000020: 4d 14 3d b8 5b 80 9d 57 2e 64 c7 95 d8 b5 a7 3b
> | 00000030: 3d 39 8a 9b 59 1c 73 12 2f 58 00 6f 28 3f 72 23
> | 00000040: ad 75 cd c0 17 2b bf 62 d2 b2 f9 b7 3f de 3e 83
> | 00000050: f2 fa e2 3a e3 03 14 84 3b 47 0e 94 ad 7f e0 dc
> | 00000060: 13 c7 56 75 3c 8f 38 88 dd 7f b7 44 b9 30 aa f6
> | 00000070: 61 dc b7 4d 72 7e 43 3e 19 a9 fb 1b d4 18 d6 1c
> | 00000080: 1d 73 9b 47 7a c9 c7 4b 30 2a 12 4f d7 1e eb bc
> | 00000090: e3 13 5b 1c f0 41 33 ae f8 81 a4 54 42 d0 fc 6c
> | 000000a0: 65 c5 b2 d8 96 43 ba 11 8d 89 a7 4d 75 e4 3e 07
> | 000000b0: 82 11 74 47 70 ff 37 5d 03 ef ec 1d 43 9b 28 10
> | 000000c0: ea 67 4e f9 10 9a f4 70 36 e6 af db cb 05 22 54
> | 000000d0: 56 41 fa 15 01 c3 ed ce 2f 15 35 df 0e fc 88 bc
> | 000000e0: c1 a9 df 2e 25 74 64 5a 21 81 e7 7d 43 ea 85 fc
> | 000000f0: 50 d2 5c e6 70 be 56 8a dc cb d1 c3 98 e5 d8 0d
> | 00000100: c5 93 2a 30 b7 0e 29 44 6a a4 ca 64 f8 a8 21 6a
> | 00000110: 48 8e fc 5f e7 d7 d3 73 20 e6 fe 97 cd d4 33 2e
> | 00000120: 0c 57 0c 55 15 e4 4e 62 cf 6a 0a 5f b0 c0 2e da
> | 00000130: 86 f8 97 7b 8c ba fc 28 11 29 60 a1 84 0e 4d be
> | 00000140: 75 04 45 8d 9b 43 e9 69 e3 46 87 8d 4c c9 c9 e8
> | 00000150: cf 35 82 38 c8 91 13 db cd 4e 8f 39 13 0f fd c9
> | 00000160: 70 73 d2 8d e3 1b 2b 3b 1d b2 bc 53 bc 05 ca 69
> | 00000170: ee c7 62 77 4e 40 d2 88 7e 1b 81 54 38 9d 98 f1
> | 00000180: ef cb dd 4b 14 50 fe 57 0a 2c 5c ed 27 a8 de e3
> | 00000190: 73 c1 55 d3 43 1a f0 98 54 7c 82 9f 7b fa 48 5c
> | 000001a0: b5 b9 90 e2 62 f4 5d 3d 28 34 34 52 47 58 9d ec
> | 000001b0: d3 82 07 aa 75 c1 7e f5 03 1f 7f 4b 89 ac a9 89
> | 000001c0: 3c 91 85 7e 5f 70 00 20 55 aa 31 84 3c a9 d2 44
> | 000001d0: 88 da 71 71 d8 e0 c3 86 c6 6e c2 5e cb 5a 6c fc
> | 000001e0: a7 52 0d bf 42 0e c2 fa 9f 59 a6 9b ca 4d fa 50
> | 000001f0: 02 fa 55 94 a7 d0 5b 68 3c 35 49 0f 49 d4 3d b4

I'll look into it.

> and the modprobe hangs.

That's not supposed to happen. Could you get a stack backtrace
to see why it's hanging?

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2009-02-06 10:18:48

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: LRW endian issues?

On Fri, 6 Feb 2009, Herbert Xu wrote:
> Geert Uytterhoeven <[email protected]> wrote:
> > When running "modprobe tcrypt mode=10" on ppc64 (PS3), I get the following
> > error:
> >
> > | alg: skcipher: Test 8 failed on encryption for lrw(aes-generic)
> > | 00000000: 1a 1d a9 30 ad f9 2f 9b b6 1d ae ef f0 2f f8 5a
> > | 00000010: 3d de 22 4d 7e b1 75 e0 d2 db 9e ba 64 b2 5d 93
> > | 00000020: 4d 14 3d b8 5b 80 9d 57 2e 64 c7 95 d8 b5 a7 3b
> > | 00000030: 3d 39 8a 9b 59 1c 73 12 2f 58 00 6f 28 3f 72 23
> > | 00000040: ad 75 cd c0 17 2b bf 62 d2 b2 f9 b7 3f de 3e 83
> > | 00000050: f2 fa e2 3a e3 03 14 84 3b 47 0e 94 ad 7f e0 dc
> > | 00000060: 13 c7 56 75 3c 8f 38 88 dd 7f b7 44 b9 30 aa f6
> > | 00000070: 61 dc b7 4d 72 7e 43 3e 19 a9 fb 1b d4 18 d6 1c
> > | 00000080: 1d 73 9b 47 7a c9 c7 4b 30 2a 12 4f d7 1e eb bc
> > | 00000090: e3 13 5b 1c f0 41 33 ae f8 81 a4 54 42 d0 fc 6c
> > | 000000a0: 65 c5 b2 d8 96 43 ba 11 8d 89 a7 4d 75 e4 3e 07
> > | 000000b0: 82 11 74 47 70 ff 37 5d 03 ef ec 1d 43 9b 28 10
> > | 000000c0: ea 67 4e f9 10 9a f4 70 36 e6 af db cb 05 22 54
> > | 000000d0: 56 41 fa 15 01 c3 ed ce 2f 15 35 df 0e fc 88 bc
> > | 000000e0: c1 a9 df 2e 25 74 64 5a 21 81 e7 7d 43 ea 85 fc
> > | 000000f0: 50 d2 5c e6 70 be 56 8a dc cb d1 c3 98 e5 d8 0d
> > | 00000100: c5 93 2a 30 b7 0e 29 44 6a a4 ca 64 f8 a8 21 6a
> > | 00000110: 48 8e fc 5f e7 d7 d3 73 20 e6 fe 97 cd d4 33 2e
> > | 00000120: 0c 57 0c 55 15 e4 4e 62 cf 6a 0a 5f b0 c0 2e da
> > | 00000130: 86 f8 97 7b 8c ba fc 28 11 29 60 a1 84 0e 4d be
> > | 00000140: 75 04 45 8d 9b 43 e9 69 e3 46 87 8d 4c c9 c9 e8
> > | 00000150: cf 35 82 38 c8 91 13 db cd 4e 8f 39 13 0f fd c9
> > | 00000160: 70 73 d2 8d e3 1b 2b 3b 1d b2 bc 53 bc 05 ca 69
> > | 00000170: ee c7 62 77 4e 40 d2 88 7e 1b 81 54 38 9d 98 f1
> > | 00000180: ef cb dd 4b 14 50 fe 57 0a 2c 5c ed 27 a8 de e3
> > | 00000190: 73 c1 55 d3 43 1a f0 98 54 7c 82 9f 7b fa 48 5c
> > | 000001a0: b5 b9 90 e2 62 f4 5d 3d 28 34 34 52 47 58 9d ec
> > | 000001b0: d3 82 07 aa 75 c1 7e f5 03 1f 7f 4b 89 ac a9 89
> > | 000001c0: 3c 91 85 7e 5f 70 00 20 55 aa 31 84 3c a9 d2 44
> > | 000001d0: 88 da 71 71 d8 e0 c3 86 c6 6e c2 5e cb 5a 6c fc
> > | 000001e0: a7 52 0d bf 42 0e c2 fa 9f 59 a6 9b ca 4d fa 50
> > | 000001f0: 02 fa 55 94 a7 d0 5b 68 3c 35 49 0f 49 d4 3d b4
>
> I'll look into it.
>
> > and the modprobe hangs.
>
> That's not supposed to happen. Could you get a stack backtrace
> to see why it's hanging?

Here's a backtrace from the RCU stall detector on PS3:

| INFO: RCU detected CPU 1 stall (t=4294906597/2500 jiffies)
| Call Trace:
| [c00000000c186fc0] [c00000000000f850] .show_stack+0x6c/0x16c (unreliable)
| [c00000000c187070] [c000000000098a04] .__rcu_pending+0x94/0x2c0
| [c00000000c187110] [c000000000098c7c] .rcu_pending+0x4c/0xa4
| [c00000000c1871b0] [c00000000005fa04] .update_process_times+0x40/0x94
| [c00000000c187240] [c00000000007b25c] .tick_sched_timer+0x154/0x1ac
| [c00000000c187300] [c000000000070df4] .__run_hrtimer+0x8c/0xfc
| [c00000000c1873a0] [c000000000071e6c] .hrtimer_interrupt+0x144/0x1e8
| [c00000000c187490] [c00000000001d46c] .timer_interrupt+0xb0/0xe4
| [c00000000c187520] [c00000000000360c] decrementer_common+0x10c/0x180
| --- Exception: 901 at .crypto_alg_mod_lookup+0x4/0xa8
| LR = .crypto_lookup_skcipher+0x38/0x2b8
| [c00000000c187810] [c0000000001bf790] .crypto_lookup_skcipher+0x284/0x2b8 (unreliable)
| [c00000000c187930] [c0000000001bf824] .crypto_alloc_ablkcipher+0x60/0xf4
| [c00000000c1879e0] [c0000000001c6454] .alg_test_skcipher+0x38/0xdc
| [c00000000c187a70] [c0000000001c6728] .alg_test+0x17c/0x1f8
| [c00000000c187b60] [d0000000026f21f0] .do_test+0x444/0xe34 [tcrypt]
| [c00000000c187c10] [d0000000026f2c48] .tcrypt_mod_init+0x64/0x41c [tcrypt]
| [c00000000c187ca0] [c000000000007eec] .do_one_initcall+0x80/0x1a4
| [c00000000c187d90] [c00000000008bcf8] .SyS_init_module+0xd8/0x234
| [c00000000c187e30] [c0000000000074dc] syscall_exit+0x0/0x40
| INFO: RCU detected CPU 1 stall (t=4294914102/10005 jiffies)
| Call Trace:
| [c00000000c186c10] [c00000000000f850] .show_stack+0x6c/0x16c (unreliable)

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium

Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010

2009-02-10 10:58:48

by Herbert Xu

[permalink] [raw]
Subject: Re: LRW endian issues?

On Fri, Feb 06, 2009 at 03:01:24PM +1100, Herbert Xu wrote:
> Geert Uytterhoeven <[email protected]> wrote:
> > When running "modprobe tcrypt mode=10" on ppc64 (PS3), I get the following
> > error:
> >
> > | alg: skcipher: Test 8 failed on encryption for lrw(aes-generic)
> > | 00000000: 1a 1d a9 30 ad f9 2f 9b b6 1d ae ef f0 2f f8 5a
> > | 00000010: 3d de 22 4d 7e b1 75 e0 d2 db 9e ba 64 b2 5d 93
> > | 00000020: 4d 14 3d b8 5b 80 9d 57 2e 64 c7 95 d8 b5 a7 3b
> > | 00000030: 3d 39 8a 9b 59 1c 73 12 2f 58 00 6f 28 3f 72 23
> > | 00000040: ad 75 cd c0 17 2b bf 62 d2 b2 f9 b7 3f de 3e 83
> > | 00000050: f2 fa e2 3a e3 03 14 84 3b 47 0e 94 ad 7f e0 dc
> > | 00000060: 13 c7 56 75 3c 8f 38 88 dd 7f b7 44 b9 30 aa f6
> > | 00000070: 61 dc b7 4d 72 7e 43 3e 19 a9 fb 1b d4 18 d6 1c
> > | 00000080: 1d 73 9b 47 7a c9 c7 4b 30 2a 12 4f d7 1e eb bc
> > | 00000090: e3 13 5b 1c f0 41 33 ae f8 81 a4 54 42 d0 fc 6c
> > | 000000a0: 65 c5 b2 d8 96 43 ba 11 8d 89 a7 4d 75 e4 3e 07
> > | 000000b0: 82 11 74 47 70 ff 37 5d 03 ef ec 1d 43 9b 28 10
> > | 000000c0: ea 67 4e f9 10 9a f4 70 36 e6 af db cb 05 22 54
> > | 000000d0: 56 41 fa 15 01 c3 ed ce 2f 15 35 df 0e fc 88 bc
> > | 000000e0: c1 a9 df 2e 25 74 64 5a 21 81 e7 7d 43 ea 85 fc
> > | 000000f0: 50 d2 5c e6 70 be 56 8a dc cb d1 c3 98 e5 d8 0d
> > | 00000100: c5 93 2a 30 b7 0e 29 44 6a a4 ca 64 f8 a8 21 6a
> > | 00000110: 48 8e fc 5f e7 d7 d3 73 20 e6 fe 97 cd d4 33 2e
> > | 00000120: 0c 57 0c 55 15 e4 4e 62 cf 6a 0a 5f b0 c0 2e da
> > | 00000130: 86 f8 97 7b 8c ba fc 28 11 29 60 a1 84 0e 4d be
> > | 00000140: 75 04 45 8d 9b 43 e9 69 e3 46 87 8d 4c c9 c9 e8
> > | 00000150: cf 35 82 38 c8 91 13 db cd 4e 8f 39 13 0f fd c9
> > | 00000160: 70 73 d2 8d e3 1b 2b 3b 1d b2 bc 53 bc 05 ca 69
> > | 00000170: ee c7 62 77 4e 40 d2 88 7e 1b 81 54 38 9d 98 f1
> > | 00000180: ef cb dd 4b 14 50 fe 57 0a 2c 5c ed 27 a8 de e3
> > | 00000190: 73 c1 55 d3 43 1a f0 98 54 7c 82 9f 7b fa 48 5c
> > | 000001a0: b5 b9 90 e2 62 f4 5d 3d 28 34 34 52 47 58 9d ec
> > | 000001b0: d3 82 07 aa 75 c1 7e f5 03 1f 7f 4b 89 ac a9 89
> > | 000001c0: 3c 91 85 7e 5f 70 00 20 55 aa 31 84 3c a9 d2 44
> > | 000001d0: 88 da 71 71 d8 e0 c3 86 c6 6e c2 5e cb 5a 6c fc
> > | 000001e0: a7 52 0d bf 42 0e c2 fa 9f 59 a6 9b ca 4d fa 50
> > | 000001f0: 02 fa 55 94 a7 d0 5b 68 3c 35 49 0f 49 d4 3d b4
>
> I'll look into it.

Does this patch help?

diff --git a/crypto/lrw.c b/crypto/lrw.c
index 8ef664e..358f80b 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -45,7 +45,13 @@ struct priv {

static inline void setbit128_bbe(void *b, int bit)
{
- __set_bit(bit ^ 0x78, b);
+ __set_bit(bit ^ (0x80 -
+#ifdef __BIG_ENDIAN
+ BITS_PER_LONG
+#else
+ BITS_PER_BYTE
+#endif
+ ), b);
}

static int setkey(struct crypto_tfm *parent, const u8 *key,

Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2009-02-10 12:02:29

by Herbert Xu

[permalink] [raw]
Subject: Re: LRW endian issues?

On Fri, Feb 06, 2009 at 11:18:46AM +0100, Geert Uytterhoeven wrote:
>
> Here's a backtrace from the RCU stall detector on PS3:
>
> | INFO: RCU detected CPU 1 stall (t=4294906597/2500 jiffies)
> | Call Trace:
> | [c00000000c186fc0] [c00000000000f850] .show_stack+0x6c/0x16c (unreliable)
> | [c00000000c187070] [c000000000098a04] .__rcu_pending+0x94/0x2c0
> | [c00000000c187110] [c000000000098c7c] .rcu_pending+0x4c/0xa4
> | [c00000000c1871b0] [c00000000005fa04] .update_process_times+0x40/0x94
> | [c00000000c187240] [c00000000007b25c] .tick_sched_timer+0x154/0x1ac
> | [c00000000c187300] [c000000000070df4] .__run_hrtimer+0x8c/0xfc
> | [c00000000c1873a0] [c000000000071e6c] .hrtimer_interrupt+0x144/0x1e8
> | [c00000000c187490] [c00000000001d46c] .timer_interrupt+0xb0/0xe4
> | [c00000000c187520] [c00000000000360c] decrementer_common+0x10c/0x180
> | --- Exception: 901 at .crypto_alg_mod_lookup+0x4/0xa8
> | LR = .crypto_lookup_skcipher+0x38/0x2b8
> | [c00000000c187810] [c0000000001bf790] .crypto_lookup_skcipher+0x284/0x2b8 (unreliable)

Thanks, could you try this patch?

diff --git a/crypto/api.c b/crypto/api.c
index 9975a7b..d80e548 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -205,6 +205,26 @@ struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alg_lookup);

+static struct crypto_alg *crypto_alg_lookup_untested(const char *name,
+ u32 type, u32 mask)
+{
+ struct crypto_alg *alg;
+
+ down_read(&crypto_alg_sem);
+ alg = __crypto_alg_lookup(name, type, mask);
+ if (!alg)
+ alg = __crypto_alg_lookup(name, type,
+ mask & ~CRYPTO_ALG_TESTED);
+ up_read(&crypto_alg_sem);
+
+ if (alg && ((alg->cra_flags ^ type) & mask & CRYPTO_ALG_TESTED)) {
+ crypto_mod_put(alg);
+ alg = ERR_PTR(-ENOENT);
+ }
+
+ return alg;
+}
+
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
@@ -220,6 +240,18 @@ struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
if (alg)
return crypto_is_larval(alg) ? crypto_larval_wait(alg) : alg;

+ /*
+ * Do not probe again if a failed algorithm already exists,
+ * or we may loop forever while churning out an endless list
+ * of failed algorithms.
+ *
+ * The user may recover from this by removing the failed
+ * algorithm.
+ */
+ alg = crypto_alg_lookup_untested(name, type, mask);
+ if (alg)
+ return alg;
+
return crypto_larval_add(name, type, mask);
}
EXPORT_SYMBOL_GPL(crypto_larval_lookup);

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2009-02-12 15:29:45

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: LRW endian issues?

On Tue, 10 Feb 2009, Herbert Xu wrote:
> On Fri, Feb 06, 2009 at 03:01:24PM +1100, Herbert Xu wrote:
> > Geert Uytterhoeven <[email protected]> wrote:
> > > When running "modprobe tcrypt mode=10" on ppc64 (PS3), I get the following
> > > error:
> > >
> > > | alg: skcipher: Test 8 failed on encryption for lrw(aes-generic)
>
> Does this patch help?
>
> diff --git a/crypto/lrw.c b/crypto/lrw.c
> index 8ef664e..358f80b 100644
> --- a/crypto/lrw.c
> +++ b/crypto/lrw.c
> @@ -45,7 +45,13 @@ struct priv {
>
> static inline void setbit128_bbe(void *b, int bit)
> {
> - __set_bit(bit ^ 0x78, b);
> + __set_bit(bit ^ (0x80 -
> +#ifdef __BIG_ENDIAN
> + BITS_PER_LONG
> +#else
> + BITS_PER_BYTE
> +#endif
> + ), b);
> }
>
> static int setkey(struct crypto_tfm *parent, const u8 *key,

Thanks! Now the test succeeds on both ppc64 and ppc32.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium

Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010

2009-02-12 15:30:13

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: LRW endian issues?

On Tue, 10 Feb 2009, Herbert Xu wrote:
> On Fri, Feb 06, 2009 at 11:18:46AM +0100, Geert Uytterhoeven wrote:
> > Here's a backtrace from the RCU stall detector on PS3:
> >
> > | INFO: RCU detected CPU 1 stall (t=4294906597/2500 jiffies)
> > | Call Trace:
> > | [c00000000c186fc0] [c00000000000f850] .show_stack+0x6c/0x16c (unreliable)
> > | [c00000000c187070] [c000000000098a04] .__rcu_pending+0x94/0x2c0
> > | [c00000000c187110] [c000000000098c7c] .rcu_pending+0x4c/0xa4
> > | [c00000000c1871b0] [c00000000005fa04] .update_process_times+0x40/0x94
> > | [c00000000c187240] [c00000000007b25c] .tick_sched_timer+0x154/0x1ac
> > | [c00000000c187300] [c000000000070df4] .__run_hrtimer+0x8c/0xfc
> > | [c00000000c1873a0] [c000000000071e6c] .hrtimer_interrupt+0x144/0x1e8
> > | [c00000000c187490] [c00000000001d46c] .timer_interrupt+0xb0/0xe4
> > | [c00000000c187520] [c00000000000360c] decrementer_common+0x10c/0x180
> > | --- Exception: 901 at .crypto_alg_mod_lookup+0x4/0xa8
> > | LR = .crypto_lookup_skcipher+0x38/0x2b8
> > | [c00000000c187810] [c0000000001bf790] .crypto_lookup_skcipher+0x284/0x2b8 (unreliable)
>
> Thanks, could you try this patch?

Unfortunately it doesn't seem to make any difference.

> diff --git a/crypto/api.c b/crypto/api.c
> index 9975a7b..d80e548 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -205,6 +205,26 @@ struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
> }
> EXPORT_SYMBOL_GPL(crypto_alg_lookup);
>
> +static struct crypto_alg *crypto_alg_lookup_untested(const char *name,
> + u32 type, u32 mask)
> +{
> + struct crypto_alg *alg;
> +
> + down_read(&crypto_alg_sem);
> + alg = __crypto_alg_lookup(name, type, mask);
> + if (!alg)
> + alg = __crypto_alg_lookup(name, type,
> + mask & ~CRYPTO_ALG_TESTED);
> + up_read(&crypto_alg_sem);
> +
> + if (alg && ((alg->cra_flags ^ type) & mask & CRYPTO_ALG_TESTED)) {
> + crypto_mod_put(alg);
> + alg = ERR_PTR(-ENOENT);
> + }
> +
> + return alg;
> +}
> +
> struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> @@ -220,6 +240,18 @@ struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
> if (alg)
> return crypto_is_larval(alg) ? crypto_larval_wait(alg) : alg;
>
> + /*
> + * Do not probe again if a failed algorithm already exists,
> + * or we may loop forever while churning out an endless list
> + * of failed algorithms.
> + *
> + * The user may recover from this by removing the failed
> + * algorithm.
> + */
> + alg = crypto_alg_lookup_untested(name, type, mask);
> + if (alg)
> + return alg;
> +
> return crypto_larval_add(name, type, mask);
> }
> EXPORT_SYMBOL_GPL(crypto_larval_lookup);

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium

Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010

2009-02-18 13:44:58

by Herbert Xu

[permalink] [raw]
Subject: Re: LRW endian issues?

On Thu, Feb 12, 2009 at 04:30:11PM +0100, Geert Uytterhoeven wrote:
>
> > Thanks, could you try this patch?
>
> Unfortunately it doesn't seem to make any difference.

Thanks for testing. I've reproduced the problem here and this
is the fix I've come up with.

commit 6fe4a28d8855e072036f36ee22f0a8f43f44918f
Author: Herbert Xu <[email protected]>
Date: Wed Feb 18 21:41:29 2009 +0800

crypto: testmgr - Test skciphers with no IVs

As it is an skcipher with no IV escapes testing altogether because
we only test givcipher objects. This patch fixes the bypass logic
to test these algorithms.

Conversely, we're currently testing nivaead algorithms with IVs,
which would have deadlocked had it not been for the fact that no
nivaead algorithms have any test vectors. This patch also fixes
that case.

Both fixes are ugly as hell, but this ugliness should hopefully
disappear once we move them into the per-type code (i.e., the
AEAD test would live in aead.c and the skcipher stuff in ablkcipher.c).

Signed-off-by: Herbert Xu <[email protected]>

diff --git a/crypto/algboss.c b/crypto/algboss.c
index 4601e42..6906f92 100644
--- a/crypto/algboss.c
+++ b/crypto/algboss.c
@@ -10,7 +10,7 @@
*
*/

-#include <linux/crypto.h>
+#include <crypto/internal/aead.h>
#include <linux/ctype.h>
#include <linux/err.h>
#include <linux/init.h>
@@ -206,8 +206,7 @@ static int cryptomgr_test(void *data)
u32 type = param->type;
int err = 0;

- if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
- CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV))
+ if (type & CRYPTO_ALG_TESTED)
goto skiptest;

err = alg_test(param->driver, param->alg, type, CRYPTO_ALG_TESTED);
@@ -223,6 +222,7 @@ static int cryptomgr_schedule_test(struct crypto_alg *alg)
{
struct task_struct *thread;
struct crypto_test_param *param;
+ u32 type;

if (!try_module_get(THIS_MODULE))
goto err;
@@ -233,7 +233,19 @@ static int cryptomgr_schedule_test(struct crypto_alg *alg)

memcpy(param->driver, alg->cra_driver_name, sizeof(param->driver));
memcpy(param->alg, alg->cra_name, sizeof(param->alg));
- param->type = alg->cra_flags;
+ type = alg->cra_flags;
+
+ /* This piece of crap needs to disappear into per-type test hooks. */
+ if ((!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
+ CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
+ ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
+ CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
+ alg->cra_ablkcipher.ivsize)) ||
+ (!((type ^ CRYPTO_ALG_TYPE_AEAD) & CRYPTO_ALG_TYPE_MASK) &&
+ alg->cra_type == &crypto_nivaead_type && alg->cra_aead.ivsize))
+ type |= CRYPTO_ALG_TESTED;
+
+ param->type = type;

thread = kthread_run(cryptomgr_test, param, "cryptomgr_test");
if (IS_ERR(thread))

commit 5852ae42424e3ddba2d3bdf594f72189497f17ee
Author: Herbert Xu <[email protected]>
Date: Wed Feb 18 20:41:47 2009 +0800

crypto: aead - Avoid infinite loop when nivaead fails selftest

When an aead constructed through crypto_nivaead_default fails
its selftest, we'll loop forever trying to construct new aead
objects but failing because it already exists.

The crux of the issue is that once an aead fails the selftest,
we'll ignore it on the next run through crypto_aead_lookup and
attempt to construct a new aead.

We should instead return an error to the caller if we find an
an that has failed the test.

This bug hasn't manifested itself yet because we don't have any
test vectors for the existing nivaead algorithms. They're tested
through the underlying algorithms only.

Signed-off-by: Herbert Xu <[email protected]>

diff --git a/crypto/aead.c b/crypto/aead.c
index 3a6f3f5..d9aa733 100644
--- a/crypto/aead.c
+++ b/crypto/aead.c
@@ -422,6 +422,22 @@ static struct crypto_alg *crypto_lookup_aead(const char *name, u32 type,
if (!alg->cra_aead.ivsize)
return alg;

+ crypto_mod_put(alg);
+ alg = crypto_alg_mod_lookup(name, type | CRYPTO_ALG_TESTED,
+ mask & ~CRYPTO_ALG_TESTED);
+ if (IS_ERR(alg))
+ return alg;
+
+ if (alg->cra_type == &crypto_aead_type) {
+ if ((alg->cra_flags ^ type ^ ~mask) & CRYPTO_ALG_TESTED) {
+ crypto_mod_put(alg);
+ alg = ERR_PTR(-ENOENT);
+ }
+ return alg;
+ }
+
+ BUG_ON(!alg->cra_aead.ivsize);
+
return ERR_PTR(crypto_nivaead_default(alg, type, mask));
}


commit b170a137f467ea951c3f256da1b911545acf3ffd
Author: Herbert Xu <[email protected]>
Date: Wed Feb 18 20:33:55 2009 +0800

crypto: skcipher - Avoid infinite loop when cipher fails selftest

When an skcipher constructed through crypto_givcipher_default fails
its selftest, we'll loop forever trying to construct new skcipher
objects but failing because it already exists.

The crux of the issue is that once a givcipher fails the selftest,
we'll ignore it on the next run through crypto_skcipher_lookup and
attempt to construct a new givcipher.

We should instead return an error to the caller if we find a
givcipher that has failed the test.

Signed-off-by: Herbert Xu <[email protected]>

diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index 94140b3..e11ce37 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -282,6 +282,25 @@ static struct crypto_alg *crypto_lookup_skcipher(const char *name, u32 type,
alg->cra_ablkcipher.ivsize))
return alg;

+ crypto_mod_put(alg);
+ alg = crypto_alg_mod_lookup(name, type | CRYPTO_ALG_TESTED,
+ mask & ~CRYPTO_ALG_TESTED);
+ if (IS_ERR(alg))
+ return alg;
+
+ if ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
+ CRYPTO_ALG_TYPE_GIVCIPHER) {
+ if ((alg->cra_flags ^ type ^ ~mask) & CRYPTO_ALG_TESTED) {
+ crypto_mod_put(alg);
+ alg = ERR_PTR(-ENOENT);
+ }
+ return alg;
+ }
+
+ BUG_ON(!((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
+ CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
+ alg->cra_ablkcipher.ivsize));
+
return ERR_PTR(crypto_givcipher_default(alg, type, mask));
}

diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index d70a41c..90d26c9 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -521,7 +521,7 @@ static int crypto_grab_nivcipher(struct crypto_skcipher_spawn *spawn,
int err;

type = crypto_skcipher_type(type);
- mask = crypto_skcipher_mask(mask) | CRYPTO_ALG_GENIV;
+ mask = crypto_skcipher_mask(mask)| CRYPTO_ALG_GENIV;

alg = crypto_alg_mod_lookup(name, type, mask);
if (IS_ERR(alg))

commit ff753308d2f70f210ba468492cd9a01274d9d7ce
Author: Herbert Xu <[email protected]>
Date: Tue Feb 17 20:18:34 2009 +0800

crypto: api - crypto_alg_mod_lookup either tested or untested

As it stands crypto_alg_mod_lookup will search either tested or
untested algorithms, but never both at the same time. However,
we need exactly that when constructing givcipher and aead so
this patch adds support for that by setting the tested bit in
type but clearing it in mask. This combination is currently
unused.

Signed-off-by: Herbert Xu <[email protected]>

diff --git a/crypto/api.c b/crypto/api.c
index efe77df..56b6e0e 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -244,7 +244,7 @@ struct crypto_alg *crypto_alg_mod_lookup(const char *name, u32 type, u32 mask)
struct crypto_alg *larval;
int ok;

- if (!(mask & CRYPTO_ALG_TESTED)) {
+ if (!((type | mask) & CRYPTO_ALG_TESTED)) {
type |= CRYPTO_ALG_TESTED;
mask |= CRYPTO_ALG_TESTED;
}

Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2009-02-18 14:14:18

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: LRW endian issues?

On Wed, 18 Feb 2009, Herbert Xu wrote:
> On Thu, Feb 12, 2009 at 04:30:11PM +0100, Geert Uytterhoeven wrote:
> >
> > > Thanks, could you try this patch?
> >
> > Unfortunately it doesn't seem to make any difference.
>
> Thanks for testing. I've reproduced the problem here and this
> is the fix I've come up with.
>
> commit 6fe4a28d8855e072036f36ee22f0a8f43f44918f
> Author: Herbert Xu <[email protected]>
> Date: Wed Feb 18 21:41:29 2009 +0800
>
> crypto: testmgr - Test skciphers with no IVs

I can confirm the test no longer hangs on "modprobe tcrypt mode=10" (after
reverting "crypto: lrw - Fix big endian support").

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village ? Da Vincilaan 7-D1 ? B-1935 Zaventem ? Belgium

Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 ? RPR Brussels
Fortis ? BIC GEBABEBB ? IBAN BE41293037680010