Cc Stephan
On (06/11/15 08:28), Herbert Xu wrote:
[..]
Thanks. And I'll make sure drbg select sha256 so that this doesn't
happen.
Thanks.
FWIW, here is my .config (Stephan has requested)
-ss
---
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.1.0-rc7 Kernel
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs.
Add a module parameter to choose whether these SoCs should be attached to
the new or the old driver.
The default policy is to keep attaching those IPs to the old driver if it
is enabled, until we decide the new CESA driver
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs.
Add a module parameter to choose whether these SoCs should be attached to
the new or the old driver.
The default policy is to keep attaching those IPs to the old driver if it
is enabled, until we decide the new CESA driver
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
Hello,
This patch series adds a new driver supporting Marvell's CESA IP.
This driver addresses some limitations of the existing one.
From a performance and CPU load point of view the most important
limitation in the existing driver is the lack of DMA support, thus
preventing us from chaining
On Dove platforms, the crypto engine requires a clock. Document this
clocks property in the mv_cesa bindings doc.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This
This patch set introduces a Public Key Encryption API.
What is proposed is a new crypto type called crypto_akcipher_type,
plus new struct akcipher_alg and struct crypto_akcipher, together with number
of helper functions to register akcipher type algorithms and allocate
tfm instances. This is to
Add a new rsa generic SW implementation.
This implements only cryptographic primitives.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig |7 +
crypto/Makefile |1
crypto/rsa.c| 289 +++
3 files changed, 297
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig |6 +
crypto/Makefile|1
crypto/akcipher.c | 154 +
crypto/crypto_user.c | 23 ++
include/crypto/akcipher.h | 408
Added a mpi_read_buf() helper function to export MPI to a buf provided by
the user, and a mpi_get_size() helper, that tells the user how big the buf is.
Implemented mpi_copy(), which was declared in mpi.h, but never implemented.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
New test vectors for RSA algorithm.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig |1
crypto/testmgr.c | 164 ++
crypto/testmgr.h | 142 +++
3 files changed, 307
Sorry for the noise: apparently I forgot to remove existing patches
when regenerating the series with format-patch.
I'll resend the series tomorrow.
On Thu, 11 Jun 2015 19:36:19 +0200
Boris Brezillon boris.brezil...@free-electrons.com wrote:
Hello,
This patch series adds a new driver
Am Thursday 11 June 2015, 20:09:29 schrieb Sergey Senozhatsky:
Hi Sergey,
Thanks.
FWIW, here is my .config (Stephan has requested)
Thank you very much. But I think Herbert already found the issue: SHA needs to
be selected too (which I erroneously thought is implicitly selected with
HMAC).
On Wed, Jun 10, 2015 at 10:27:48PM +0900, Sergey Senozhatsky wrote:
Be more verbose and also report -backend_cra_name when
crypto_alloc_shash() or crypto_alloc_cipher() fail in
drbg_init_hash_kernel() or drbg_init_sym_kernel()
correspondingly.
Example
DRBG: could not allocate digest TFM
Am Thursday 11 June 2015, 15:59:29 schrieb Tadeusz Struk:
Hi Tadeusz,
Hi Stephan,
On 02/28/2015 11:50 AM, Stephan Mueller wrote:
+err = af_alg_wait_for_completion(ctx-enc ?
+ crypto_aead_encrypt(ctx-aead_req) :
+
Hi Stephan,
On 02/28/2015 11:50 AM, Stephan Mueller wrote:
+ err = af_alg_wait_for_completion(ctx-enc ?
+ crypto_aead_encrypt(ctx-aead_req) :
+ crypto_aead_decrypt(ctx-aead_req),
+
On Fri, Jun 12, 2015 at 10:42:46AM +0800, Herbert Xu wrote:
On Fri, Jun 12, 2015 at 03:00:42AM +0200, Stephan Mueller wrote:
The testmgr code can mark an entire cipher implementation as fips_allowed=1
as
already done for RSA. However, unlike with the other ciphers, that flag
must
On Thu, Jun 11, 2015 at 12:05:44PM -0700, Tadeusz Struk wrote:
+int crypto_akcipher_setkey(struct crypto_akcipher *tfm,
+const struct public_key *pkey)
+{
+ if (tfm-pkey)
+ akcipher_free_key(tfm-pkey);
+
+ return akcipher_clone_key(tfm, pkey);
Am Thursday 11 June 2015, 12:05:44 schrieb Tadeusz Struk:
Hi Tadeusz,
+
+static int akcipher_clone_key(struct crypto_akcipher *tfm,
+const struct public_key *pkey)
+{
+ int i, ret = 0;
+
+ tfm-pkey = kzalloc(sizeof(*tfm-pkey), GFP_KERNEL);
+
+ if
On Thu, Jun 11, 2015 at 12:05:38PM -0700, Tadeusz Struk wrote:
+/**
+ * mpi_get_size() - returns max size required to store the number
+ *
+ * @a: A multi precision integer for which we want to allocate a bufer
+ *
+ * Return: size required to store the number
+ */
+unsigned int
On Fri, Jun 12, 2015 at 03:00:42AM +0200, Stephan Mueller wrote:
The testmgr code can mark an entire cipher implementation as fips_allowed=1
as
already done for RSA. However, unlike with the other ciphers, that flag must
go in conjunction with the used key sizes.
For FIPS mode, the
42 matches
Mail list logo
