linux-stable.git/drivers/crypto, branch v3.18.48

crypto: caam - fix AEAD givenc descriptors

2017-01-13T23:00:21+00:00

[ Upstream commit d128af17876d79b87edf048303f98b35f6a53dbc ]

The AEAD givenc descriptor relies on moving the IV through the
output FIFO and then back to the CTX2 for authentication. The
SEQ FIFO STORE could be scheduled before the data can be
read from OFIFO, especially since the SEQ FIFO LOAD needs
to wait for the SEQ FIFO LOAD SKIP to finish first. The
SKIP takes more time when the input is SG than when it's
a contiguous buffer. If the SEQ FIFO LOAD is not scheduled
before the STORE, the DECO will hang waiting for data
to be available in the OFIFO so it can be transferred to C2.
In order to overcome this, first force transfer of IV to C2
by starting the "cryptlen" transfer first and then starting to
store data from OFIFO to the output buffer.

Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation")
Cc:  # 3.2+
Signed-off-by: Alex Porosanu 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: caam - fix non-hmac hashes

2016-08-31T23:26:24+00:00

[ Upstream commit a0118c8b2be9297aed8e915c60b4013326b256d4 ]

Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
accept(2)"), the AF_ALG interface requires userspace to provide a key
to any algorithm that has a setkey method.  However, the non-HMAC
algorithms are not keyed, so setting a key is unnecessary.

Fix this by removing the setkey method from the non-keyed hash
algorithms.

Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)")
Cc: 
Signed-off-by: Russell King 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ux500 - memmove the right size

2016-07-11T15:16:08+00:00

[ Upstream commit 19ced623db2fe91604d69f7d86b03144c5107739 ]

The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.

Cc: Joakim Bech 
Cc: stable@vger.kernel.org
Reported-by: David Binderman 
Signed-off-by: Linus Walleij 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - Fix AES XTS error for request sizes above 4096

2016-06-18T20:52:51+00:00

[ Upstream commit ab6a11a7c8ef47f996974dd3c648c2c0b1a36ab1 ]

The ccp-crypto module for AES XTS support has a bug that can allow requests
greater than 4096 bytes in size to be passed to the CCP hardware. The CCP
hardware does not support request sizes larger than 4096, resulting in
incorrect output. The request should actually be handled by the fallback
mechanism instantiated by the ccp-crypto module.

Add a check to insure the request size is less than or equal to the maximum
supported size and use the fallback mechanism if it is not.

Cc:  # 3.14.x-
Signed-off-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: caam - fix caam_jr_alloc() ret code

2016-06-06T23:11:01+00:00

[ Upstream commit e930c765ca5c6b039cd22ebfb4504ea7b5dab43d ]

caam_jr_alloc() used to return NULL if a JR device could not be
allocated for a session. In turn, every user of this function used
IS_ERR() function to verify if anything went wrong, which does NOT look
for NULL values. This made the kernel crash if the sanity check failed,
because the driver continued to think it had allocated a valid JR dev
instance to the session and at some point it tries to do a caam_jr_free()
on a NULL JR dev pointer.
This patch is a fix for this issue.

Cc: 
Signed-off-by: Catalin Vasile 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

2016-06-03T15:30:28+00:00

[ Upstream commit 79152e8d085fd64484afd473ef6830b45518acba ]

The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
testing 8 kB size blocks:

	$ sudo modprobe tcrypt sec=1 mode=500
	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
	test 4 (128 bit key, 8192 byte blocks):

This was caused by a race issue of missed BRDMA_DONE ("Block cipher
Receiving DMA") interrupt. Device starts processing the data in DMA mode
immediately after setting length of DMA block: receiving (FCBRDMAL) or
transmitting (FCBTDMAL). The driver sets these lengths from interrupt
handler through s5p_set_dma_indata() function (or xxx_setdata()).

However the interrupt handler was first dealing with receive buffer
(dma-unmap old, dma-map new, set receive block length which starts the
operation), then with transmit buffer and finally was clearing pending
interrupts (FCINTPEND). Because of the time window between setting
receive buffer length and clearing pending interrupts, the operation on
receive buffer could end already and driver would miss new interrupt.

User manual for Exynos5422 confirms in example code that setting DMA
block lengths should be the last operation.

The tcrypt hang could be also observed in following blocked-task dmesg:

INFO: task modprobe:258 blocked for more than 120 seconds.
      Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
modprobe        D c06b09d8     0   258    256 0x00000000
[] (__schedule) from [] (schedule+0x40/0xac)
[] (schedule) from [] (schedule_timeout+0x124/0x178)
[] (schedule_timeout) from [] (wait_for_common+0xb8/0x144)
[] (wait_for_common) from [] (test_acipher_speed+0x49c/0x740 [tcrypt])
[] (test_acipher_speed [tcrypt]) from [] (do_test+0x2240/0x30ec [tcrypt])
[] (do_test [tcrypt]) from [] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
[] (tcrypt_mod_init [tcrypt]) from [] (do_one_initcall+0x3c/0x16c)
[] (do_one_initcall) from [] (do_init_module+0x5c/0x1ac)
[] (do_init_module) from [] (load_module+0x1a30/0x1d08)
[] (load_module) from [] (SyS_finit_module+0x8c/0x98)
[] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x3c)

Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
Cc: 
Signed-off-by: Krzysztof Kozlowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: s5p-sss - Remove useless hash interrupt handler

2016-06-03T15:30:28+00:00

[ Upstream commit 5512442553bbe8d4fcdba3e17b30f187706384a7 ]

Beside regular feed control interrupt, the driver requires also hash
interrupt for older SoCs (samsung,s5pv210-secss). However after
requesting it, the interrupt handler isn't doing anything with it, not
even clearing the hash interrupt bit.

Driver does not provide hash functions so it is safe to remove the hash
interrupt related code and to not require the interrupt in Device Tree.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - Prevent information leakage on export

2016-05-09T01:21:51+00:00

[ Upstream commit f709b45ec461b548c41a00044dba1f1b572783bf ]

Prevent information from leaking to userspace by doing a memset to 0 of
the export state structure before setting the structure values and copying
it. This prevents un-initialized padding areas from being copied into the
export area.

Cc:  # 3.14.x-
Reported-by: Ben Hutchings 
Signed-off-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - memset request context to zero during import

2016-04-18T12:49:19+00:00

[ Upstream commit ce0ae266feaf35930394bd770c69778e4ef03ba9 ]

Since a crypto_ahash_import() can be called against a request context
that has not had a crypto_ahash_init() performed, the request context
needs to be cleared to insure there is no random data present. If not,
the random data can result in a kernel oops during crypto_ahash_update().

Cc:  # 3.14.x-
Signed-off-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - Don't assume export/import areas are aligned

2016-04-12T13:10:24+00:00

[ Upstream commit b31dde2a5cb1bf764282abf934266b7193c2bc7c ]

Use a local variable for the exported and imported state so that
alignment is not an issue. On export, set a local variable from the
request context and then memcpy the contents of the local variable to
the export memory area. On import, memcpy the import memory area into
a local variable and then use the local variable to set the request
context.

Cc:  # 3.14.x-
Signed-off-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin