| Message ID | 224788c7-426b-d3a9-d0a6-412d2b8afb75@partner.samsung.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Herbert Xu |
| Headers | show |
On Mon, Feb 5, 2018 at 6:40 PM, Kamil Konieczny <k.konieczny@partner.samsung.com> wrote: > > In AES-ECB mode crypt is done with key only, so any use of IV > can cause kernel Oops, as reported by Anand Moon. > Fixed it by using IV only in AES-CBC and AES-CTR. > > Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> > Reported-by: Anand Moon <linux.amoon@gmail.com> > --- > Tested on Odroid XU4/HC1, kernel 4.15 with following command: > > fallocate -l 128MiB /tmp/test.bin > dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1 > sync > cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin > > The original report by Anand Moon: > https://www.spinics.net/lists/linux-crypto/msg31180.html > > Oops reproduced with cryptsetup 2.0.0, kernel 4.15, > in .config in crypto API ECB support was turned off, and s5p-sss AES driver on. > > cryptsetup is using aes-ecb and has req->info in aes_ctx set to 0x10, > which caused Oops: > > [ 2078.683779] Internal error: Oops: 17 [#1] PREEMPT SMP ARM > [ 2078.689148] Modules linked in: algif_skcipher af_alg sd_mod sg > evdev uas usb_storage scsi_mod gpio_keys fbtft(C) spidev spi_s3c64xx > ipv6 > [ 2078.701377] CPU: 1 PID: 15 Comm: ksoftirqd/1 Tainted: G C > 4.15.0-rc9-xu4krck #1 > [ 2078.709861] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 2078.715932] PC is at memcpy+0x80/0x330 > [ 2078.719652] LR is at s5p_tasklet_cb+0x19c/0x328 > > drivers/crypto/s5p-sss.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) Fixes and cc-stable? Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
Hi Kamil, Thanks for providing the fix to this issue. On 5 February 2018 at 23:10, Kamil Konieczny <k.konieczny@partner.samsung.com> wrote: > > In AES-ECB mode crypt is done with key only, so any use of IV > can cause kernel Oops, as reported by Anand Moon. If possible could you avoid the name in commit message. > Fixed it by using IV only in AES-CBC and AES-CTR. > > Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> > Reported-by: Anand Moon <linux.amoon@gmail.com> [snip] Please add my. Tested on Odroid HC2 Tested-by: Anand Moon <linux.amoon@gmail.com> Below are the result at my end. aes-cbc-essiv:sha256 (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 11.7225 s, 71.6 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 22.112 s, 37.9 MB/s aes-cbc-essiv:sha256 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 13.096 s, 64.1 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 24.4165 s, 34.4 MB/s aes-ctr-plain (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 11.2246 s, 74.7 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 20.426 s, 41.1 MB/s aes-xts-plain64 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 11.1533 s, 75.2 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 20.8821 s, 40.2 MB/s aes-xts-plain64 (512 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 12.0614 s, 69.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 23.0717 s, 36.4 MB/s twofish-cbc-essiv:sha256 (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 13.031 s, 64.4 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 20.7202 s, 40.5 MB/s twofish-cbc-essiv:sha256 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 12.9995 s, 64.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 24.2369 s, 34.6 MB/s twofish-xts-plain64 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 14.607 s, 57.4 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 26.2963 s, 31.9 MB/s twofish-xts-plain64 (512 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 14.5783 s, 57.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 25.3593 s, 33.1 MB/s serpent-cbc-essiv:sha256 (128 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 15.5157 s, 54.1 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 37.0526 s, 22.6 MB/s serpent-cbc-essiv:sha256 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 16.1138 s, 52.1 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 36.922 s, 22.7 MB/s serpent-xts-plain64 (256 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 17.287 s, 48.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 39.279 s, 21.4 MB/s serpent-xts-plain64 (512 bit key) WRITE: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 16.9464 s, 49.5 MB/s READ: 100+0 records in 100+0 records out 838860800 bytes (839 MB, 800 MiB) copied, 38.3389 s, 21.9 MB/s Best Regards -Anand
On 06.02.2018 17:48, Anand Moon wrote: > Hi Kamil, > > Thanks for providing the fix to this issue. > > On 5 February 2018 at 23:10, Kamil Konieczny > <k.konieczny@partner.samsung.com> wrote: >> >> In AES-ECB mode crypt is done with key only, so any use of IV >> can cause kernel Oops, as reported by Anand Moon. > > If possible could you avoid the name in commit message. This is added after '---' line, so it will not appear in commit message. >> Fixed it by using IV only in AES-CBC and AES-CTR. >> >> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> >> Reported-by: Anand Moon <linux.amoon@gmail.com> > > [snip] > > Please add my. Tested on Odroid HC2 > > Tested-by: Anand Moon <linux.amoon@gmail.com> This will add you name in commit message, additionally with 'Reported-by:' line. > Below are the result at my end. > > aes-cbc-essiv:sha256 (128 bit key) > WRITE: > 100+0 records in > 100+0 records out > 838860800 bytes (839 MB, 800 MiB) copied, 11.7225 s, 71.6 MB/s > [...] is it from 'cryptsetup benchmark' ? benchmark did not cause oops. Please test with luksFormat, ie. use cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin
Hi Kamil On 6 February 2018 at 22:40, Kamil Konieczny <k.konieczny@partner.samsung.com> wrote: > > On 06.02.2018 17:48, Anand Moon wrote: >> Hi Kamil, >> >> Thanks for providing the fix to this issue. >> >> On 5 February 2018 at 23:10, Kamil Konieczny >> <k.konieczny@partner.samsung.com> wrote: >>> >>> In AES-ECB mode crypt is done with key only, so any use of IV >>> can cause kernel Oops, as reported by Anand Moon. >> >> If possible could you avoid the name in commit message. > > This is added after '---' line, so it will not appear in commit message. > I know about '---' delimiter, but to be precise this will be part of commit message. >>> Fixed it by using IV only in AES-CBC and AES-CTR. >>> >>> Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> >>> Reported-by: Anand Moon <linux.amoon@gmail.com> >> >> [snip] >> >> Please add my. Tested on Odroid HC2 >> >> Tested-by: Anand Moon <linux.amoon@gmail.com> > > This will add you name in commit message, > additionally with 'Reported-by:' line. > >> Below are the result at my end. >> >> aes-cbc-essiv:sha256 (128 bit key) >> WRITE: >> 100+0 records in >> 100+0 records out >> 838860800 bytes (839 MB, 800 MiB) copied, 11.7225 s, 71.6 MB/s >> [...] > > is it from 'cryptsetup benchmark' ? benchmark did not cause oops. > Please test with luksFormat, ie. use > > cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin > [snip] Below is the out put of aes-cbc-essiv:sha256 and aes-ctr-plain root@odroid:~# fallocate -l 128MiB /tmp/test.bin root@odroid:~# dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1 1+0 records in 1+0 records out 128 bytes copied, 0.000231043 s, 554 kB/s root@odroid:~# sync root@odroid:~# cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin # cryptsetup 1.6.6 processing "cryptsetup luksFormat --debug -q -d /tmp/testkey.key --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin" # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /tmp/test.bin context. # Trying to open and read device /tmp/test.bin. # Initialising device-mapper backend library. # Timeout set to 0 miliseconds. # Iteration time set to 1000 miliseconds. # File descriptor passphrase entry requested. # Formatting device /tmp/test.bin as type LUKS1. # Crypto backend (gcrypt 1.6.5) initialized. # Detected kernel Linux 4.15.0-xu4krck armv7l. # Topology info for /tmp/test.bin not supported, using default offset 1048576 bytes. # Checking if cipher aes-cbc-essiv:sha256 is usable. # Using userspace crypto wrapper to access keyslot area. # Generating LUKS header version 1 using hash sha256, aes, cbc-essiv:sha256, MK 16 bytes # KDF pbkdf2, hash sha256: 160824 iterations per second. # Data offset 2048, UUID fe5c0d54-9add-4454-a4cd-98eed8f2b75c, digest iterations 19625 # Updating LUKS header of size 1024 on device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Reading LUKS header of size 1024 from device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Adding new keyslot -1 using volume key. # Calculating data for key slot 0 # KDF pbkdf2, hash sha256: 161220 iterations per second. # Key slot 0 use 78720 password iterations. # Using hash sha256 for AF in key slot 0, 4000 stripes # Updating key slot 0 [0x1000] area. # Using userspace crypto wrapper to access keyslot area. # Key slot 0 was enabled in LUKS header. # Updating LUKS header of size 1024 on device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Reading LUKS header of size 1024 from device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Releasing crypt device /tmp/test.bin context. # Releasing device-mapper backend. # Unlocking memory. Command successful. root@odroid:~# root@odroid:~# root@odroid:~# fallocate -l 128MiB /tmp/test.bin root@odroid:~# dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1 1+0 records in 1+0 records out 128 bytes copied, 0.000324001 s, 395 kB/s root@odroid:~# sync root@odroid:~# cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ > --cipher aes-ctr-plain -h sha256 -s 128 /tmp/test.bin # cryptsetup 1.6.6 processing "cryptsetup luksFormat --debug -q -d /tmp/testkey.key --cipher aes-ctr-plain -h sha256 -s 128 /tmp/test.bin" # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /tmp/test.bin context. # Trying to open and read device /tmp/test.bin. # Initialising device-mapper backend library. # Timeout set to 0 miliseconds. # Iteration time set to 1000 miliseconds. # File descriptor passphrase entry requested. # Formatting device /tmp/test.bin as type LUKS1. # Crypto backend (gcrypt 1.6.5) initialized. # Detected kernel Linux 4.15.0-xu4krck armv7l. # Topology info for /tmp/test.bin not supported, using default offset 1048576 bytes. # Checking if cipher aes-ctr-plain is usable. # Using userspace crypto wrapper to access keyslot area. # Generating LUKS header version 1 using hash sha256, aes, ctr-plain, MK 16 bytes # KDF pbkdf2, hash sha256: 162217 iterations per second. # Data offset 2048, UUID 3e2b2e4a-a908-4228-b2a1-746e163e8e7e, digest iterations 19750 # Updating LUKS header of size 1024 on device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Reading LUKS header of size 1024 from device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Adding new keyslot -1 using volume key. # Calculating data for key slot 0 # KDF pbkdf2, hash sha256: 160234 iterations per second. # Key slot 0 use 78239 password iterations. # Using hash sha256 for AF in key slot 0, 4000 stripes # Updating key slot 0 [0x1000] area. # Using userspace crypto wrapper to access keyslot area. # Key slot 0 was enabled in LUKS header. # Updating LUKS header of size 1024 on device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Reading LUKS header of size 1024 from device /tmp/test.bin # Key length 16, device size 262144 sectors, header size 1029 sectors. # Releasing crypt device /tmp/test.bin context. # Releasing device-mapper backend. # Unlocking memory. Command successful. Best Regards -Anand
On Mon, Feb 05, 2018 at 06:40:20PM +0100, Kamil Konieczny wrote: > > In AES-ECB mode crypt is done with key only, so any use of IV > can cause kernel Oops, as reported by Anand Moon. > Fixed it by using IV only in AES-CBC and AES-CTR. > > Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> > Reported-by: Anand Moon <linux.amoon@gmail.com> Patch applied. Thanks.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 142c6020cec7..5c0496d1ed41 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -1926,15 +1926,21 @@ static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, unsigned long mode) uint32_t aes_control; unsigned long flags; int err; + u8 *iv; aes_control = SSS_AES_KEY_CHANGE_MODE; if (mode & FLAGS_AES_DECRYPT) aes_control |= SSS_AES_MODE_DECRYPT; - if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) + if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) { aes_control |= SSS_AES_CHAIN_MODE_CBC; - else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) + iv = req->info; + } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) { aes_control |= SSS_AES_CHAIN_MODE_CTR; + iv = req->info; + } else { + iv = NULL; /* AES_ECB */ + } if (dev->ctx->keylen == AES_KEYSIZE_192) aes_control |= SSS_AES_KEY_SIZE_192; @@ -1965,7 +1971,7 @@ static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, unsigned long mode) goto outdata_error; SSS_AES_WRITE(dev, AES_CONTROL, aes_control); - s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen); + s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen); s5p_set_dma_indata(dev, dev->sg_src); s5p_set_dma_outdata(dev, dev->sg_dst);
In AES-ECB mode crypt is done with key only, so any use of IV can cause kernel Oops, as reported by Anand Moon. Fixed it by using IV only in AES-CBC and AES-CTR. Signed-off-by: Kamil Konieczny <k.konieczny@partner.samsung.com> Reported-by: Anand Moon <linux.amoon@gmail.com> --- Tested on Odroid XU4/HC1, kernel 4.15 with following command: fallocate -l 128MiB /tmp/test.bin dd if=/dev/urandom of=/tmp/testkey.key bs=128 count=1 sync cryptsetup luksFormat --debug -q -d /tmp/testkey.key \ --cipher aes-cbc-essiv:sha256 -h sha256 -s 128 /tmp/test.bin The original report by Anand Moon: https://www.spinics.net/lists/linux-crypto/msg31180.html Oops reproduced with cryptsetup 2.0.0, kernel 4.15, in .config in crypto API ECB support was turned off, and s5p-sss AES driver on. cryptsetup is using aes-ecb and has req->info in aes_ctx set to 0x10, which caused Oops: [ 2078.683779] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 2078.689148] Modules linked in: algif_skcipher af_alg sd_mod sg evdev uas usb_storage scsi_mod gpio_keys fbtft(C) spidev spi_s3c64xx ipv6 [ 2078.701377] CPU: 1 PID: 15 Comm: ksoftirqd/1 Tainted: G C 4.15.0-rc9-xu4krck #1 [ 2078.709861] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2078.715932] PC is at memcpy+0x80/0x330 [ 2078.719652] LR is at s5p_tasklet_cb+0x19c/0x328 drivers/crypto/s5p-sss.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)