On Thu, Jun 11, 2015 at 11:50:06PM -0700, Tadeusz Struk wrote:
>
> Should I make it MPI[] rather than void *
It should be in encoded format since only the algorithms should
be decoding it. Otherwise you have craziness where RSA-specific
knowledge is placed into x509_cert_parser.c to parse RSA key
On 06/11/2015 07:59 PM, Herbert Xu 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);
>> > +}
>
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,
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
>
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
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, th
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);
>+
>+
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),
> +
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 wrote:
> Hello,
>
> This patch series adds a new driver supporting Marvell's CESA IP.
> This d
New test vectors for RSA algorithm.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |1
crypto/testmgr.c | 164 ++
crypto/testmgr.h | 142 +++
3 files changed, 307 insertions(+)
diff --git a
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
---
include/linux/mpi.h |3 ++
lib
Add a new rsa generic SW implementation.
This implements only cryptographic primitives.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |7 +
crypto/Makefile |1
crypto/rsa.c| 289 +++
3 files changed, 297 insertions(+)
create m
Add Public Key Encryption API.
Signed-off-by: Tadeusz Struk
---
crypto/Kconfig |6 +
crypto/Makefile|1
crypto/akcipher.c | 154 +
crypto/crypto_user.c | 23 ++
include/crypto/akcipher.h | 408 ++
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
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
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
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
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
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
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
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
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
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 | 157 ++
3 files change
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(+)
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
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 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
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
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 | 157 ++
3 files change
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 | 170 +-
3 files changed,
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 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 e4dfee0..087370e 10064
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
---
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 e4dfee0..087370e 10064
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 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 | 170 +-
3 files changed,
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
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
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
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
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 -
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 diges
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).
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 Config
46 matches
Mail list logo
