Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

[Herbert Xu]

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 
> Reported-by: Anand Moon 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

[Anand Moon]

Hi Kamil

On 6 February 2018 at 22:40, Kamil Konieczny
 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
>>  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 
>>> Reported-by: Anand Moon 
>>
>> [snip]
>>
>> Please add my. Tested on Odroid HC2
>>
>> Tested-by: Anand Moon 
>
> 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 

Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

[Kamil Konieczny]

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
>  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 
>> Reported-by: Anand Moon 
> 
> [snip]
> 
> Please add my. Tested on Odroid HC2
> 
> Tested-by: Anand Moon 

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

Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

[Anand Moon]

Hi Kamil,

Thanks for providing the fix to this issue.

On 5 February 2018 at 23:10, 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.

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 
> Reported-by: Anand Moon 

[snip]

Please add my. Tested on Odroid HC2

Tested-by: Anand Moon 

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

Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

[Krzysztof Kozlowski]

On Mon, Feb 5, 2018 at 6:40 PM, 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 
> Reported-by: Anand Moon 
> ---
> 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 

Best regards,
Krzysztof

[PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

[Kamil Konieczny]

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 
Reported-by: Anand Moon 
---
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