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 <[email protected]>
Reported-by: Anand Moon <[email protected]>
---
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(-)
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);
--
2.16.0
On Mon, Feb 5, 2018 at 6:40 PM, Kamil Konieczny
<[email protected]> 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 <[email protected]>
> Reported-by: Anand Moon <[email protected]>
> ---
> 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 <[email protected]>
Best regards,
Krzysztof
Hi Kamil,
Thanks for providing the fix to this issue.
On 5 February 2018 at 23:10, Kamil Konieczny
<[email protected]> 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 <[email protected]>
> Reported-by: Anand Moon <[email protected]>
[snip]
Please add my. Tested on Odroid HC2
Tested-by: Anand Moon <[email protected]>
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
> <[email protected]> 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 <[email protected]>
>> Reported-by: Anand Moon <[email protected]>
>
> [snip]
>
> Please add my. Tested on Odroid HC2
>
> Tested-by: Anand Moon <[email protected]>
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
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
Hi Kamil
On 6 February 2018 at 22:40, Kamil Konieczny
<[email protected]> 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
>> <[email protected]> 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 <[email protected]>
>>> Reported-by: Anand Moon <[email protected]>
>>
>> [snip]
>>
>> Please add my. Tested on Odroid HC2
>>
>> Tested-by: Anand Moon <[email protected]>
>
> 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 <[email protected]>
> Reported-by: Anand Moon <[email protected]>
Patch applied. Thanks.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt