RE: [PATCH] crypto: xts - Add support for Cipher Text Stealing

[Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>]

Milan,


> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of
> Pascal Van Leeuwen
> Sent: Tuesday, August 6, 2019 9:37 PM
> To: Milan Broz <gmazyland@gmail.com>; Pascal van Leeuwen <pascalvanl@gmail.com>; linux-
> crypto@vger.kernel.org
> Cc: rsnel@cube.dyndns.org; herbert@gondor.apana.org.au; davem@davemloft.net
> Subject: RE: [PATCH] crypto: xts - Add support for Cipher Text Stealing
> 
> Milan,
> 
> Thanks for trying :-)
> 
> > -----Original Message-----
> > From: Milan Broz <gmazyland@gmail.com>
> > Sent: Tuesday, August 6, 2019 8:35 PM
> > To: Pascal van Leeuwen <pascalvanl@gmail.com>; linux-crypto@vger.kernel.org
> > Cc: rsnel@cube.dyndns.org; herbert@gondor.apana.org.au; davem@davemloft.net; Pascal Van
> > Leeuwen <pvanleeuwen@verimatrix.com>
> > 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@verimatrix.com>
> >
> > 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.
> 
Ok, I tried this on my kernel but it works just fine.
But if I understand correctly, you run a 32 bit kernel under some VM or so?
Perhaps that does some stricter buffer overflow checks? In any case, I
wouldn't know how to do that ...

> > (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.
> 
Actually, it turns out I had everything enabled already except adiantum, which
should not be relevant for XTS anyway. But it actually doesn't matter much,
since (my) testmgr only has CTS vectors for AES, so the CTS code is not hit for
anything else unless you run some application that does so.

> 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 ...
> 
I went through the code a couple of times, but I cannot spot any mistakes in
the lengths I'm using. Is it possible that your application is supplying a
buffer that is just not large enough?

> > 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

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com