[PATCH] Documentation: crypto - add akcipher API

Reference the new akcipher API calls in the kernel crypto API DocBook. Also, fix the comments in the akcipher.h file: double dashes do not look good in the DocBook and fix a typo. Signed-off-by: Stephan Mueller --- Documentation/DocBook/crypto-API.tmpl | 24

crypto: ahash - Add crypto_ahash_blocksize

On Sun, Oct 18, 2015 at 05:23:30PM +0100, Russell King wrote: > There's an easier way to get at the hash transform - rather than > using crypto_ahash_tfm(ahash), we can get it directly from > req->base.tfm. > > Signed-off-by: Russell King This should be converted to

[PATCH v2 5/5] crypto: algif_akcipher - enable compilation

Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 9 + crypto/Makefile | 1 + 2 files changed, 10 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index fc93444..aa5d3aa

[PATCH v2 4/5] crypto: AF_ALG -- add asymmetric cipher interface

This patch adds the user space interface for asymmetric ciphers. The interface allows the use of sendmsg as well as vmsplice to provide data. Signed-off-by: Stephan Mueller --- crypto/algif_akcipher.c | 542 1 file changed,

[PATCH v2 2/5] crypto: AF_ALG -- add sign/verify API

Add the flags for handling signature generation and signature verification. Also, the patch adds the interface for setting a public key. Signed-off-by: Stephan Mueller --- include/uapi/linux/if_alg.h | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v2 0/5] crypto: add algif_akcipher user space API

Hi, This patch set adds the AF_ALG user space API to externalize the asymmetric cipher API recently added to the kernel crypto API. The patch set is tested with the user space library of libkcapi [1]. Use [1] test/test.sh for a full test run. The test covers the following scenarios: *

[PATCH v2 3/5] crypto: AF_ALG -- add setpubkey setsockopt call

For supporting asymmetric ciphers, user space must be able to set the public key. The patch adds a new setsockopt call for setting the public key. Signed-off-by: Stephan Mueller --- crypto/af_alg.c | 14 +++--- include/crypto/if_alg.h | 1 + 2 files

[PATCH v2 1/5] MPI: fix off by one in mpi_read_raw_from_sgl

The patch fixes the analysis of the input data which contains an off by one. The issue is visible when the SGL contains one byte per SG entry. The code for checking for zero bytes does not operate on the data byte. Signed-off-by: Stephan Mueller --- lib/mpi/mpicoder.c | 5

Re: [PATCH 00/18] crypto: further fixes for Marvell CESA hash

Hi, Boris Brezillon writes: > On Sun, 18 Oct 2015 17:16:49 +0100 > Russell King - ARM Linux wrote: > >> Following on from the previous series, this series addresses further >> problems with the Marvell CESA hash driver found while

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote: > Hi, > > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. > > The patch set is tested with the user space library of libkcapi [1]. > Use [1]

[PATCH 3/4] hwrng: exynos - Fix missing configuration after suspend to RAM

After suspend to RAM the device stopped to work with ETIMEDOUT error: $ dd if=/dev/hwrng of=/dev/null bs=1 count=16 dd: reading `/dev/hwrng': Connection timed out In the STATUS register the bits #5 (PRNG_DONE) and #1 (SEED_SETTING_DONE) were not set. Instead PRNG_ERROR (seventh bit) was high.

Re: [PATCH 3/4] hwrng: exynos - Fix missing configuration after suspend to RAM

On 19.10.2015 13:37, Krzysztof Kozlowski wrote: > After suspend to RAM the device stopped to work with ETIMEDOUT error: > > $ dd if=/dev/hwrng of=/dev/null bs=1 count=16 > dd: reading `/dev/hwrng': Connection timed out > > In the STATUS register the bits #5 (PRNG_DONE) and #1 >

[PATCH 0/4] hwrng: exynos - Add Device Tree support

Hi, The patchset fixes known issues in Exynos hardware random number generator and adds Device Tree support for it. The device was tested on Trats2 board (Exynos4412). It should work on other Exynos4 and Exynos5 as well... altough it seems that on some of Exynos542x boards the SSS module is

[PATCH 2/3] ARM: dts: Add PRNG module for exynos4

Add Pseudo Random Number Generator (PRNG) node of Security Sub System (SSS) to Exynos 4 DTSI. Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi

[PATCH 3/3] ARM: dts: Enable PRNG module on exynos4412-trats2

Enable Pseudo Random Number Generator (PRNG) on Trats2 board. This allows using hardware random number generator: $ echo exynos > /sys/class/misc/hw_random/rng_current Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4412-trats2.dts | 4 1 file

[PATCH 4/4] hwrng: exynos - Add Device Tree support

Add Device Tree support for the driver. The Pseudo Random Number Generator module is the same in almost all of Exynos SoCs, since Exynos4210 (however the tests were done only on Trats2 board with Exynos4412). There are some differences on newer Exynos Octa (Exynos542x) SoCs. Signed-off-by:

[PATCH 1/4] dt-bindings: rng: Describe Exynos4 PRNG bindings

Document the bindings used by exynos-rng Pseudo Random Number Generator driver. Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/rng/samsung,exynos-rng4.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644

[PATCH 2/4] hwrng: exynos - Add timeout for waiting on init done

Driver may hang waiting indefinitely for PRNG to finish its initialization stage. Instead of stalling return -ETIMEDOUT error. Signed-off-by: Krzysztof Kozlowski --- drivers/char/hw_random/exynos-rng.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

[PATCH 0/3] ARM: dts: Enable Exynos RNG module

Hi, The patchset adds necessary clock from Security SubSystem (SSS) and enables the PRNG module of Exynos for Trats2 board. The first patch (clock) is required for other ones so please take everything in one step. The actual Device Tree support (and compatible) was sent in separate patch: -

Re: [PATCH] hwrng: exynos - Fix unbalanced PM runtime get/puts

On 17.10.2015 01:01, Daniel Thompson wrote: > Currently this driver calls pm_runtime_get_sync() rampantly > but never puts anything back. This makes it impossible for the > device to autosuspend properly; it will remain fully active > after the first use. > > Fix in the obvious way. > >

[PATCH 00/18] crypto: further fixes for Marvell CESA hash

Following on from the previous series, this series addresses further problems with the Marvell CESA hash driver found while testing it my openssl/ssh scenarios. The first patch improves one from the previous series: we can get the transform more directly using req->base.tfm rather than going

[PATCH 08/18] crypto: marvell: factor out adding an operation and launching it

Add a helper to add the fragment operation block followed by the DMA entry to launch the operation. Although at the moment this pattern only strictly appears at one site, two other sites can be factored as well by slightly changing the order in which the DMA operations are performed. This should

[PATCH 12/18] crypto: marvell: ensure iter.base.op_len is the full op length

When we process the last request of data, and the request contains user data, the loop in mv_cesa_ahash_dma_req_init() marks the first data size as being iter.base.op_len which does not include the size of the cache data. This means we end up hashing an insufficient amount of data. Fix this by

[PATCH 10/18] crypto: marvell: move mv_cesa_dma_add_frag() calls

Move the calls to mv_cesa_dma_add_frag() into the parent function, mv_cesa_ahash_dma_req_init(). This is in preparation to changing when we generate the operation blocks, as we need to avoid generating a block for a partial hash block at the end of the user data. Signed-off-by: Russell King

[PATCH 14/18] crypto: marvell: rearrange last request handling

Move the test for the last request out of mv_cesa_ahash_dma_last_req() to its caller, and move the mv_cesa_dma_add_frag() down into this function. Signed-off-by: Russell King --- drivers/crypto/marvell/hash.c | 30 +++--- 1 file changed, 19

[PATCH 04/18] crypto: marvell: fix the bit length endianness

The endianness of the bit length used in the final stage depends on the endianness of the algorithm - md5 hashes need it to be in little endian format, whereas SHA hashes need it in big endian format. Use the previously added algorithm endianness flag to control this. Signed-off-by: Russell King

[PATCH 03/18] crypto: marvell: add flag to determine algorithm endianness

Rather than determining whether we're using a MD5 hash by looking at the digest size, switch to a cleaner solution using a per-request flag initialised by the method type. Signed-off-by: Russell King --- drivers/crypto/marvell/cesa.h | 1 +

[PATCH 02/18] crypto: marvell: keep creq->state in CPU endian format at all times

Currently, we read/write the state in CPU endian, but on the final request, we convert its endian according to the requested algorithm. (md5 is little endian, SHA are big endian.) Always keep creq->state in CPU native endian format, and perform the necessary conversion when copying the hash to

[PATCH 05/18] crypto: marvell: ensure template operation is initialised

Ensure that the template operation is fully initialised, otherwise we end up loading data from the kernel stack into the engines, which can upset the hash results. Signed-off-by: Russell King --- drivers/crypto/marvell/hash.c | 12 ++-- 1 file changed, 6

[PATCH 09/18] crypto: marvell: always ensure mid-fragments after first-fragment

If we add a template first-fragment operation, always update the template to be a mid-fragment. This ensures that mid-fragments always follow on from a first fragment in every case. This means we can move the first to mid-fragment update code out of mv_cesa_ahash_dma_add_data(). Signed-off-by:

[PATCH 13/18] crypto: marvell: avoid adding final operation within loop

Avoid adding the final operation within the loop, but instead add it outside. We combine this with the handling for the no-data case. Signed-off-by: Russell King --- drivers/crypto/marvell/hash.c | 24 +--- 1 file changed, 17 insertions(+), 7

[PATCH 07/18] crypto: marvell: factor out first fragment decisions to helper

Multiple locations in the driver test the operation context fragment type, checking whether it is a first fragment or not. Introduce a mv_cesa_mac_op_is_first_frag() helper, which returns true if the fragment operation is for a first fragment. Signed-off-by: Russell King

[PATCH 17/18] crypto: marvell: fix first-fragment handling in mv_cesa_ahash_dma_last_req()

When adding the software padding, this must be done using the first/mid fragment mode, and any subsequent operation needs to be a mid-fragment. Fix this. Signed-off-by: Russell King --- drivers/crypto/marvell/hash.c | 8 1 file changed, 8 deletions(-) diff

[PATCH 06/18] crypto: marvell: const-ify argument to mv_cesa_get_op_cfg()

mv_cesa_get_op_cfg() does not write to its argument, it only reads. So, let's make it const. Signed-off-by: Russell King --- drivers/crypto/marvell/cesa.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/marvell/cesa.h

[PATCH 11/18] crypto: marvell: use presence of scatterlist to determine data load

Use the presence of the scatterlist to determine whether we should load any new user data to the engine. The following shall always be true at this point: iter.base.op_len == 0 === iter.src.sg In doing so, we can: 1. eliminate the test for iter.base.op_len inside the loop, which

[PATCH 15/18] crypto: marvell: rearrange handling for hw finished hashes

Rearrange the last request handling for hardware finished hashes by moving the generation of the fragment operation into this path. This results in a simplified sequence to handle this case, and allows us to move the software padded case further down into the function. Add comments describing

[PATCH 18/18] crypto: marvell/cesa: fix memory leak

From: Boris Brezillon To: Boris Brezillon ,Arnaud Ebalard ,Thomas Petazzoni ,Jason Cooper The local chain variable is not cleaned up if an

[PATCH 16/18] crypto: marvell: rearrange handling for sw padded hashes

Rearrange the last request handling for hashes which require software padding. We prepare the padding to be appended, and then append as much of the padding to any existing data that's already queued up, adding an operation block and launching the operation. Any remainder is then appended as a

Re: [PATCH 00/18] crypto: further fixes for Marvell CESA hash

Hi Russell On Sun, 18 Oct 2015 17:16:49 +0100 Russell King - ARM Linux wrote: > Following on from the previous series, this series addresses further > problems with the Marvell CESA hash driver found while testing it my > openssl/ssh scenarios. > > The first patch

Re: [PATCH 0/6] Sparse related fixes

On Sun, 18 Oct 2015 18:30:39 +0100 Russell King - ARM Linux wrote: > Continuing on from the previous set of 18 patches, I also fixed a > number of sparse problems and other cleanups. I don't deem these > suitable for -rc merging, especially now that we're basically at >

[PATCH v2 0/6] Fix CAAM hash driver

The following series fixes the CAAM hash driver, allowing it to work with the previously merged "crypto: ahash - ensure statesize is non- zero" patch. This is non-trivial, because CAAM exports a huge 1600 bytes of data, which, if we set .statesize to this, still results in the core code rejecting

[PATCH 1/6] crypto: caam: print errno code when hash registration fails

Print the errno code when hash registration fails, so we know why the failure occurred. This aids debugging. Signed-off-by: Russell King --- drivers/crypto/caam/caamhash.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git

[PATCH 3/6] crypto: caam: fix non-block aligned hash calculation

caam does not properly calculate the size of the retained state when non-block aligned hashes are requested - it uses the wrong buffer sizes, which results in errors such as: caam_jr 2102000.jr1: 4501: DECO: desc idx 5: SGT Length Error. The descriptor is trying to read more data than is

[PATCH 2/6] crypto: caam: avoid needlessly saving and restoring caam_hash_ctx

When exporting and importing the hash state, we will only export and import into hashes which share the same struct crypto_ahash pointer. (See hash_accept->af_alg_accept->hash_accept_parent.) This means that saving the caam_hash_ctx structure on export, and restoring it on import is a waste of

[PATCH 5/6] crypto: caam: fix indentation of close braces

The kernel's coding style suggests that closing braces for initialisers should not be aligned to the open brace column. The CodingStyle doc shows how this should be done. Remove the additional tab. Signed-off-by: Russell King --- drivers/crypto/caam/caamhash.c |

[PATCH 4/6] crypto: caam: only export the state we really need to export

Avoid exporting lots of state by only exporting what we really require, which is the buffer containing the set of pending bytes to be hashed, number of pending bytes, the context buffer, and the function pointer state. This reduces down the exported state size to 216 bytes from 576 bytes.

[PATCH 6/6] crypto: caam: fix DMA API leak

caamhash contains this weird code: src_nents = sg_count(req->src, req->nbytes, ); dma_map_sg_chained(jrdev, req->src, src_nents ? : 1, DMA_TO_DEVICE, chained); ... edesc->src_nents = src_nents; sg_count() returns zero when __sg_count()

[PATCH 5/6] crypto: marvell: fix missing cpu_to_le32() in mv_cesa_dma_add_op()

When tdma->src is freed in mv_cesa_dma_cleanup(), we convert the DMA address from a little-endian value prior to calling dma_pool_free(). However, mv_cesa_dma_add_op() assigns tdma->src without first converting the DMA address to little endian. Fix this. Signed-off-by: Russell King

[PATCH 6/6] crypto: marvell: use __le32 for hardware descriptors

Much of the driver uses cpu_to_le32() to convert values for descriptors to little endian before writing. Use __le32 to define the hardware- accessed parts of the descriptors, and ensure most places where it's reasonable to do so use cpu_to_le32() when assigning to these. Signed-off-by: Russell

[PATCH 2/6] crypto: marvell: use dma_addr_t for cur_dma

cur_dma is part of the software state, not read by the hardware. Storing it in LE32 format is wrong, use dma_addr_t for this. Signed-off-by: Russell King --- drivers/crypto/marvell/cesa.h | 4 +++- drivers/crypto/marvell/tdma.c | 6 +++--- 2 files changed, 6

[PATCH 4/6] crypto: marvell: use memcpy_fromio()/memcpy_toio()

Use the IO memcpy() functions when copying from/to MMIO memory. These locations were found via sparse. Signed-off-by: Russell King --- drivers/crypto/marvell/cipher.c | 11 ++- drivers/crypto/marvell/hash.c | 16 2 files changed, 14

[PATCH 3/6] crypto: marvell: use gfp_t for gfp flags

Use gfp_t not u32 for the GFP flags. Signed-off-by: Russell King --- drivers/crypto/marvell/cesa.h | 6 ++ drivers/crypto/marvell/tdma.c | 5 ++--- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/marvell/cesa.h

[PATCH 1/6] crypto: marvell: use readl_relaxed()/writel_relaxed()

Use relaxed IO accessors where appropriate. Signed-off-by: Russell King --- drivers/crypto/marvell/cesa.h | 2 +- drivers/crypto/marvell/cipher.c | 2 +- drivers/crypto/marvell/hash.c | 7 +++ drivers/crypto/marvell/tdma.c | 20 ++-- 4

[PATCH 0/6] Sparse related fixes

Continuing on from the previous set of 18 patches, I also fixed a number of sparse problems and other cleanups. I don't deem these suitable for -rc merging, especially now that we're basically at -rc6. The first patch switches the driver over to appropriately using the relaxed IO accessors -