This patch fixes a number of problems in crypto driver Kconfig
entries:
1. Select BLKCIPHER instead of BLKCIPHER2. The latter is internal
and should not be used outside of the crypto API itself.
2. Do not select ALGAPI unless you use a legacy type like
CRYPTO_ALG_TYPE_CIPHER.
3. Select the algori
The AEAD speed test SG list setup did not correctly mark the AD,
potentially causing a crash.
Signed-off-by: Herbert Xu
---
crypto/tcrypt.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 5146367..9f6f10b 100644
--- a
This patch adds a speed test for rfc4309(ccm(aes)) as mode 212.
Signed-off-by: Herbert Xu
---
crypto/tcrypt.c |5 +
crypto/tcrypt.h |1 +
2 files changed, 6 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 4b4a931..5146367 100644
--- a/crypto/tcrypt.c
+++ b/crypto
On Tue, Jun 16, 2015 at 11:58:58AM +0200, Boris Brezillon wrote:
>
> +config CRYPTO_DEV_MARVELL_CESA
> + tristate "New Marvell's Cryptographic Engine driver"
> + depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) && HAS_DMA &&
> HAS_IOMEM
> + select CRYPTO_ALGAPI
> + select CRYP
On Wed, Jun 17, 2015 at 01:05:27PM +0800, Herbert Xu wrote:
> On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote:
> >
> > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > +DMA_TO_DEVICE);
> > + if (ret != creq->src_nents)
> > + return -
On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote:
>
> + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> + DMA_TO_DEVICE);
> + if (ret != creq->src_nents)
> + return -ENOMEM;
Hmm it doesn't quite work like that. It returns zero o
On 06/16/2015 07:36 PM, Herbert Xu wrote:
> The existing crypto/asymmetric_key errno scheme doesn't really
> mesh in with the rest of crypto. So you'll just have to pick one
> scheme and stick with it.
>
> I don't really mind either way as long as the error codes are
> unique and meaningful.
So
On Tue, Jun 16, 2015 at 07:32:16PM -0700, Tadeusz Struk wrote:
>
> I thought that -EBADMSG was mainly used for authenticated ciphers in case
> when verification of auth data fails.
> Since this are input params I thought that -EINVAL would be more appropriate.
> I can change it to -EBADMSG, no pro
Hi David,
On 06/16/2015 03:10 PM, David Howells wrote:
>> +static int _rsa_sign(const struct rsa_key *key, MPI s, MPI m)
>> > +{
>> > + /* (1) Validate 0 <= m < n */
>> > + if (mpi_cmp_ui(m, 0) < 0 || mpi_cmp(m, key->n) >= 0)
>> > + return -EINVAL;
> Why -EINVAL not -EBADMSG?
I thought
Tadeusz Struk wrote:
> +static int _rsa_sign(const struct rsa_key *key, MPI s, MPI m)
> +{
> + /* (1) Validate 0 <= m < n */
> + if (mpi_cmp_ui(m, 0) < 0 || mpi_cmp(m, key->n) >= 0)
> + return -EINVAL;
Why -EINVAL not -EBADMSG?
David
--
To unsubscribe from this list: send th
Add a new rsa generic SW implementation.
This implements only cryptographic primitives.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig|7 +
crypto/Makefile |8 +
crypto/rsa.c | 315 +
crypto/rsa_help
New test vectors for RSA algorithm.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |1
crypto/testmgr.c | 158 ++
crypto/testmgr.h | 187 ++
3 files changed, 346 insertions(+)
diff --git a/
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 mak
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig | 11 +
crypto/Makefile|1
crypto/akcipher.c | 117
crypto/crypto_user.c | 22 ++
include/crypto/akcipher.h | 340
Jon,
The patches published to the mailing list yesterday for comment (titled crypto:
caam - Add i.MX6 support to the Freescale CAAM driver) are based on the patches
in the Freescale 3.14 git repository which enable i.MX6 support. The initial
patch set is intended to provide a functional driver,
Hi!
On Tue, Jun 16, 2015 at 03:27:54AM +, Victoria Milhoan wrote:
> All,
>
> Freescale has been adding i.MX6 support to the CAAM driver and testing on
> both i.MX6 and QorIQ platforms. The patch series is now available for review.
> Your feedback for the provided patches is appreciated.
>
The patch
crypto: caam - Add definition of rd/wr_reg64 for little endian platform
added support for little endian platforms to the CAAM driver. Namely a
write and read function for 64 bit registers.
The only user of this functions is the Job Ring driver
(drivers/crypto/caam/jr.c).
It use
From: Arnaud Ebalard
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed,
From: Arnaud Ebalard
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 file
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 commi
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 9c43cd7e..af590bf 1006
Add support for DES operations.
Signed-off-by: Boris Brezillon
Signed-off-by: Arnaud Ebalard
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff -
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
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 ret
From: Arnaud Ebalard
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
Signed-off-by: Boris Brezillon
---
driver
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
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files change
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 support
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 exa
On Dove platforms, the crypto engine requires a clock. Document this
clocks property in the mv_cesa bindings doc.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto
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 cryp
Add iv_out information to all CBC testvec so that the testmgr can verify
the IV value after each cipher request.
Signed-off-by: Boris Brezillon
---
crypto/testmgr.h | 81
1 file changed, 81 insertions(+)
diff --git a/crypto/testmgr.h b/cr
Hello,
Crypto drivers are supposed to update the IV passed to a cipher request
but it appears that some of them are not updating it.
The first patch of this series adds a new test for cipher algo (test the IV
value after a cipher operation) and the second one adds the expected IV value
to all the
The crypto drivers are supposed to update the IV passed to the crypto
request before calling the completion callback.
Test for the IV value before considering the test as successful.
Signed-off-by: Boris Brezillon
---
crypto/testmgr.c | 12 +++-
crypto/testmgr.h | 1 +
2 files changed,
The Poly1305 authenticator requires a unique key for each generated tag. This
implies that we can't set the key per tfm, as multiple users set individual
keys. Instead we pass a desc specific key as the first two blocks of the
message to authenticate in update().
Signed-off-by: Martin Willi
---
On Tue, Jun 16, 2015 at 01:02:05AM -0700, Tadeusz Struk wrote:
>
> + if (!pkey->n || !pkey->e || !req->dst_len)
> + return -EINVAL;
You leaked m.
> + if (*req->dst_len < mpi_get_size(pkey->n)) {
> + *req->dst_len = mpi_get_size(pkey->n);
> + return -EIN
On Tue, Jun 16, 2015 at 01:01:59AM -0700, Tadeusz Struk wrote:
>
> @@ -28,6 +28,7 @@ crypto_hash-y += shash.o
> obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
>
> obj-$(CONFIG_CRYPTO_PCOMP2) += pcompress.o
> +obj-$(CONFIG_CRYPTO_AKCIPHER) += akcipher.o
s/AKCIPHER/AKCIPHER2/
> +/**
> + * struct a
Victoria,
I was hoping you would join the conversation. I know you have a
series of patches in Freescale's 3.14 git repository. Have you
updated those for mainline and published them for review and inclusion
in the upstream kernel? If yes to any could you post a link?
-Jon
On Tue, Jun 16, 201
New test vectors for RSA algorithm.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |1
crypto/testmgr.c | 161 ++
crypto/testmgr.h | 187 ++
3 files changed, 349 insertions(+)
diff --git a/
Add a new rsa generic SW implementation.
This implements only cryptographic primitives.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig|7 +
crypto/Makefile |8 +
crypto/rsa.c | 313 +
crypto/rsa_help
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 mak
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig | 11 +
crypto/Makefile|1
crypto/akcipher.c | 100 +++
crypto/crypto_user.c | 22 ++
include/crypto/akcipher.h | 323
Hi!
On Mon, Jun 15, 2015 at 05:28:16PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 15, 2015 at 05:59:07PM +0200, Steffen Trumtrar wrote:
> > I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current
> > drivers/crypto/caam driver only works for PowerPC AFAIK.
> > Actually, the
44 matches
Mail list logo
