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
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig | 11 +
crypto/Makefile|1
crypto/akcipher.c | 117
crypto/crypto_user.c | 22 ++
New test vectors for RSA algorithm.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig |1
crypto/testmgr.c | 158 ++
crypto/testmgr.h | 187 ++
3 files changed, 346
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 |8 +
crypto/rsa.c | 315
Tadeusz Struk tadeusz.st...@intel.com 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
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 -ENOMEM;
Hmm
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 CRYPTO_AES
+
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 on error,
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 that -EBADMSG was
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
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 I
On Mon, Jun 15, 2015 at 04:52:53PM -0700, Victoria Milhoan wrote:
@@ -91,9 +91,14 @@ static int dma_map_sg_chained(struct device *dev, struct
scatterlist *sg,
{
if (unlikely(chained)) {
int i;
+ struct scatterlist *tsg = sg;
+
+ /* We use a local copy of the
On Mon, Jun 15, 2015 at 11:26:58PM -0700, Tadeusz Struk wrote:
On 06/15/2015 05:37 PM, Herbert Xu wrote:
config CRYPTO_MANAGER
tristate Cryptographic algorithm manager
select CRYPTO_MANAGER2
+select CRYPTO_AKCIPHER
Please add this to CRYPTO_MANAGER2
On 06/15/2015 05:37 PM, Herbert Xu wrote:
config CRYPTO_MANAGER
tristate Cryptographic algorithm manager
select CRYPTO_MANAGER2
+ select CRYPTO_AKCIPHER
Please add this to CRYPTO_MANAGER2 instead.
This causes a recursive dependency error
crypto/Kconfig:115:error: recursive
On Mon, Jun 15, 2015 at 01:18:36PM -0700, Tadeusz Struk wrote:
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.
Changed mpi_free to use kzfree instead of kfree because it is used to free
On Mon, Jun 15, 2015 at 04:52:56PM -0700, Victoria Milhoan wrote:
From: Steve Cornelius steve.cornel...@freescale.com
Multiple function in asynchronous hashing use a saved-state block,
a.k.a. struct caam_hash_state, which holds a stash of information
between requests (init/update/final).
On Mon, Jun 15, 2015 at 04:52:59PM -0700, Victoria Milhoan wrote:
From: Steve Cornelius steve.cornel...@freescale.com
The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx)
allocated in one DMA-tagged region. While the kernel's heap allocator
should place the overall
On Mon, Jun 15, 2015 at 04:52:58PM -0700, Victoria Milhoan wrote:
Fix a Trying to vfree() nonexistent vm area error when unloading the CAAM
controller module by providing the correct pointer value to iounmap().
Signed-off-by: Victoria Milhoan vicki.milh...@freescale.com
Applied.
--
Email:
On Mon, Jun 15, 2015 at 04:52:57PM -0700, Victoria Milhoan wrote:
The CAAM driver uses two data buffers to store data for a hashing operation,
with one buffer defined as active. This change forces switching of the
active buffer when executing a hashing operation to avoid a later DMA unmap
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 -EINVAL;
+ }
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 Public Key Encryption API.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/Kconfig | 11 +
crypto/Makefile|1
crypto/akcipher.c | 100 +++
crypto/crypto_user.c | 22 ++
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
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
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 |8 +
crypto/rsa.c | 313
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
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 boris.brezil...@free-electrons.com
---
crypto/testmgr.c | 12 +++-
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 boris.brezil...@free-electrons.com
---
crypto/testmgr.h | 81
1 file changed, 81 insertions(+)
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 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 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 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 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
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
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
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
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
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
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 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 +
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 +
44 matches
Mail list logo
