Milan, Thanks for trying :-) > -----Original Message----- > From: Milan Broz <gmazyland@xxxxxxxxx> > Sent: Tuesday, August 6, 2019 8:35 PM > To: Pascal van Leeuwen <pascalvanl@xxxxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx > Cc: rsnel@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Pascal Van > Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Subject: Re: [PATCH] crypto: xts - Add support for Cipher Text Stealing > > On 06/08/2019 08:55, Pascal van Leeuwen wrote: > > This adds support for Cipher Text Stealing for data blocks that are not an > > integer multiple of the cipher block size in size, bringing it fully in > > line with the IEEE P1619/D16 standard. > > > > This has been tested with the AES-XTS test vectors from the IEEE P1619/D16 > > specification as well as some additional test vectors supplied to the > > linux_crypto mailing list previously. It has also been fuzzed against > > Inside Secure AES-XTS hardware which has been actively used in the field > > for more than a decade already. > > > > Signed-off-by: Pascal van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > > Wow, it was quick... thanks for this! :) > > I tried to test with my wrapper through AF_ALG (with the discussed test vectors), > but it crashed my 32bit i686 VM (Linus tree with your patch applied) > Ok, I have to admit I only tried it on one particular kernel configuration. I don't really have the time nor the resources (I also have to work on this machine, so I need it to be stable ...) to really try other configurations. > To reproduce it, run this "kernel" af_alg branch of extracted cryptsetup vector testsuite: > https://github.com/mbroz/cryptsetup_backend_test/tree/kernel > I'll try that tomorrow if I can get it to work without too much effort. > (output) ... > CIPHER vector 00: [aes-ecb,128bits][serpent-ecb,128bits] > CIPHER vector 01: [aes-cbc,128bits][serpent-cbc,128bits] > CIPHER vector 02: [aes-ecb,256bits][serpent-ecb,256bits] > CIPHER vector 03: [aes-cbc,256bits][serpent-cbc,256bits] > CIPHER vector 04: [aes-xts,256bits][serpent-xts,256bits] > CIPHER vector 05: [aes-xts,512bits][serpent-xts,512bits] > CIPHER vector 06: [xchacha12,aes-adiantum,256bits][xchacha20,aes-adiantum,256bits] > Segmentation fault > I also noticed some algorithms that I don't think I have configured into my kernel at the moment (never occurred to me really, I try not to touch my kernel config so I don't break it and I wasn't originally interested in these as I can't think of any use case for them), maybe I should try enabling those with my kernel first. I know there's part of the code I can't hit with xts(aes), but I also didn't know how to otherwise hit it, maybe one of these does hit that and reveals a bug there. > > (If you cannot reproduce it, I'll check it tomorrow. It is quite possible > I have a bug in wrapper, but it should definitely not OOPS the kernel... > moreover, this crash is possible from a user context) > > Thanks, > Milan > > > OOPS log here: > > kernel: detected buffer overflow in memcpy > Ok, so I probably messed up some length somewhere :-) Let's see if I can spot it by careful review ... > kernel: ------------[ cut here ]------------ > kernel: kernel BUG at lib/string.c:1115! > kernel: invalid opcode: 0000 [#1] PREEMPT SMP > kernel: CPU: 1 PID: 2303 Comm: tst Not tainted 5.3.0-rc3+ #572 > kernel: Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, > BIOS 6.00 04/13/2018 > kernel: EIP: fortify_panic+0xe/0x19 > kernel: Code: b6 00 00 00 00 8b 45 e4 83 c4 10 5b 5e 29 f8 5f 5d c3 0f b6 c2 0f b6 f3 29 f0 > eb ce 55 89 e5 50 68 70 03 8d c1 e8 cc 27 a6 ff <0f> 0b 90 90 90 90 90 90 90 90 90 55 89 e5 > 57 56 53 89 d3 83 ec 04 > kernel: EAX: 00000022 EBX: f1418dc8 ECX: f40ab784 EDX: 00000001 > kernel: ESI: f317a318 EDI: 00000020 EBP: f0c2bdf4 ESP: f0c2bdec > kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010286 > kernel: CR0: 80050033 CR2: b7f543a0 CR3: 30e2a000 CR4: 00140690 > kernel: Call Trace: > kernel: encrypt_finish_cts.cold+0xa/0xa > kernel: encrypt+0xe7/0x100 > kernel: crypto_skcipher_encrypt+0xe/0x20 > kernel: skcipher_recvmsg+0x2f5/0x390 [algif_skcipher] > kernel: sock_read_iter+0x86/0xd0 > kernel: __vfs_read+0x140/0x1f0 > kernel: vfs_read+0x8b/0x150 > kernel: ksys_read+0x5c/0xd0 > kernel: sys_read+0x11/0x20 > kernel: do_int80_syscall_32+0x4b/0x1a0 > kernel: entry_INT80_32+0xfb/0xfb > kernel: EIP: 0xb7f64092 > kernel: Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 > 2c 00 00 00 66 90 00 00 00 00 00 00 00 00 cd 80 <c3> 8d b4 26 00 00 00 00 8d b6 00 00 00 00 > 8b 1c 24 c3 8d b4 26 00 > kernel: EAX: ffffffda EBX: 00000004 ECX: bfde1d3c EDX: 00000025 > kernel: ESI: b7f57000 EDI: 00000000 EBP: bfde1cb8 ESP: bfde1bcc > kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000282 > kernel: Modules linked in: nhpoly1305 chacha_generic adiantum poly1305_generic > serpent_sse2_i586 serpent_generic glue_helper algif_skcipher rmd160 wp512 sha512_generic > sha1_generic algif_hash af_alg loop dm_mod pktcdvd crc32_pclmul crc32c_intel aesni_intel > aes_i586 crypto_simd cryptd ata_piix > kernel: ---[ end trace 29d18b04feffc139 ]--- Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
