* [PATCH v7 6/9] crypto: acomp - add support for lz4hc via scomp
From: Giovanni Cabiddu @ 2016-09-13 12:49 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Giovanni Cabiddu
In-Reply-To: <1473770981-9869-1-git-send-email-giovanni.cabiddu@intel.com>
Add scomp backend for lz4hc compression algorithm
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
crypto/Kconfig | 1 +
crypto/lz4hc.c | 147 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 138 insertions(+), 10 deletions(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index e95cbbd..4258e85 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1615,6 +1615,7 @@ config CRYPTO_LZ4
config CRYPTO_LZ4HC
tristate "LZ4HC compression algorithm"
select CRYPTO_ALGAPI
+ select CRYPTO_ACOMP2
select LZ4HC_COMPRESS
select LZ4_DECOMPRESS
help
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index a1d3b5b..d509901 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -22,37 +22,59 @@
#include <linux/crypto.h>
#include <linux/vmalloc.h>
#include <linux/lz4.h>
+#include <crypto/scatterwalk.h>
+#include <crypto/internal/scompress.h>
+
+#define LZ4HC_SCRATCH_SIZE 131072
struct lz4hc_ctx {
void *lz4hc_comp_mem;
};
+static void * __percpu *lz4hc_src_scratches;
+static void * __percpu *lz4hc_dst_scratches;
+
+static void *lz4hc_alloc_ctx(struct crypto_scomp *tfm)
+{
+ void *ctx;
+
+ ctx = vmalloc(LZ4HC_MEM_COMPRESS);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+
+ return ctx;
+}
+
static int lz4hc_init(struct crypto_tfm *tfm)
{
struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
- ctx->lz4hc_comp_mem = vmalloc(LZ4HC_MEM_COMPRESS);
- if (!ctx->lz4hc_comp_mem)
+ ctx->lz4hc_comp_mem = lz4hc_alloc_ctx(NULL);
+ if (IS_ERR(ctx->lz4hc_comp_mem))
return -ENOMEM;
return 0;
}
+static void lz4hc_free_ctx(struct crypto_scomp *tfm, void *ctx)
+{
+ vfree(ctx);
+}
+
static void lz4hc_exit(struct crypto_tfm *tfm)
{
struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
- vfree(ctx->lz4hc_comp_mem);
+ lz4hc_free_ctx(NULL, ctx->lz4hc_comp_mem);
}
-static int lz4hc_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
- unsigned int slen, u8 *dst, unsigned int *dlen)
+static int __lz4hc_compress_crypto(const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen, void *ctx)
{
- struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
size_t tmp_len = *dlen;
int err;
- err = lz4hc_compress(src, slen, dst, &tmp_len, ctx->lz4hc_comp_mem);
+ err = lz4hc_compress(src, slen, dst, &tmp_len, ctx);
if (err < 0)
return -EINVAL;
@@ -61,8 +83,18 @@ static int lz4hc_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
return 0;
}
-static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
- unsigned int slen, u8 *dst, unsigned int *dlen)
+static int lz4hc_compress_crypto(struct crypto_tfm *tfm, const u8 *src,
+ unsigned int slen, u8 *dst,
+ unsigned int *dlen)
+{
+ struct lz4hc_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ return __lz4hc_compress_crypto(src, slen, dst, dlen,
+ ctx->lz4hc_comp_mem);
+}
+
+static int __lz4hc_decompress_crypto(const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen, void *ctx)
{
int err;
size_t tmp_len = *dlen;
@@ -76,6 +108,59 @@ static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
return err;
}
+static int lz4hc_decompress_crypto(struct crypto_tfm *tfm, const u8 *src,
+ unsigned int slen, u8 *dst,
+ unsigned int *dlen)
+{
+ return __lz4hc_decompress_crypto(src, slen, dst, dlen, NULL);
+}
+
+static int lz4hc_scomp_comp_decomp(struct crypto_scomp *tfm,
+ struct scatterlist *src, unsigned int slen,
+ struct scatterlist *dst, unsigned int *dlen,
+ void *ctx, int dir)
+{
+ const int cpu = get_cpu();
+ u8 *scratch_src = *per_cpu_ptr(lz4hc_src_scratches, cpu);
+ u8 *scratch_dst = *per_cpu_ptr(lz4hc_dst_scratches, cpu);
+ int ret;
+
+ if (slen > LZ4HC_SCRATCH_SIZE || *dlen > LZ4HC_SCRATCH_SIZE) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ scatterwalk_map_and_copy(scratch_src, src, 0, slen, 0);
+ if (dir)
+ ret = __lz4hc_compress_crypto(scratch_src, slen, scratch_dst,
+ dlen, ctx);
+ else
+ ret = __lz4hc_decompress_crypto(scratch_src, slen, scratch_dst,
+ dlen, NULL);
+ if (!ret)
+ scatterwalk_map_and_copy(scratch_dst, dst, 0, *dlen, 1);
+
+out:
+ put_cpu();
+ return ret;
+}
+
+static int lz4hc_scomp_compress(struct crypto_scomp *tfm,
+ struct scatterlist *src, unsigned int slen,
+ struct scatterlist *dst, unsigned int *dlen,
+ void *ctx)
+{
+ return lz4hc_scomp_comp_decomp(tfm, src, slen, dst, dlen, ctx, 1);
+}
+
+static int lz4hc_scomp_decompress(struct crypto_scomp *tfm,
+ struct scatterlist *src, unsigned int slen,
+ struct scatterlist *dst, unsigned int *dlen,
+ void *ctx)
+{
+ return lz4hc_scomp_comp_decomp(tfm, src, slen, dst, dlen, ctx, 0);
+}
+
static struct crypto_alg alg_lz4hc = {
.cra_name = "lz4hc",
.cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
@@ -89,14 +174,56 @@ static struct crypto_alg alg_lz4hc = {
.coa_decompress = lz4hc_decompress_crypto } }
};
+static struct scomp_alg scomp = {
+ .alloc_ctx = lz4hc_alloc_ctx,
+ .free_ctx = lz4hc_free_ctx,
+ .compress = lz4hc_scomp_compress,
+ .decompress = lz4hc_scomp_decompress,
+ .base = {
+ .cra_name = "lz4hc",
+ .cra_driver_name = "lz4hc-scomp",
+ .cra_module = THIS_MODULE,
+ }
+};
+
static int __init lz4hc_mod_init(void)
{
- return crypto_register_alg(&alg_lz4hc);
+ int ret;
+
+ lz4hc_src_scratches = crypto_scomp_alloc_scratches(LZ4HC_SCRATCH_SIZE);
+ if (!lz4hc_src_scratches)
+ return -ENOMEM;
+
+ lz4hc_dst_scratches = crypto_scomp_alloc_scratches(LZ4HC_SCRATCH_SIZE);
+ if (!lz4hc_dst_scratches) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ ret = crypto_register_alg(&alg_lz4hc);
+ if (ret)
+ goto error;
+
+ ret = crypto_register_scomp(&scomp);
+ if (ret) {
+ crypto_unregister_alg(&alg_lz4hc);
+ goto error;
+ }
+
+ return ret;
+
+error:
+ crypto_scomp_free_scratches(lz4hc_src_scratches);
+ crypto_scomp_free_scratches(lz4hc_dst_scratches);
+ return ret;
}
static void __exit lz4hc_mod_fini(void)
{
crypto_unregister_alg(&alg_lz4hc);
+ crypto_unregister_scomp(&scomp);
+ crypto_scomp_free_scratches(lz4hc_src_scratches);
+ crypto_scomp_free_scratches(lz4hc_dst_scratches);
}
module_init(lz4hc_mod_init);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] crypto: qat - fix resource release omissions
From: Quentin Lambert @ 2016-09-13 12:56 UTC (permalink / raw)
To: Herbert Xu, Giovanni Cabiddu
Cc: Salvatore Benedetto, David S. Miller, qat-linux, linux-crypto,
linux-kernel, kernel-janitors, giovanni.cabiddu
In-Reply-To: <20160913124006.GB31835@gondor.apana.org.au>
On 13/09/2016 14:40, Herbert Xu wrote:
> On Tue, Sep 06, 2016 at 11:18:51AM +0100, Giovanni Cabiddu wrote:
>> ---8<---
>> Subject: [PATCH] crypto: qat - fix leak on error path
>>
>> Fix a memory leak in an error path in uc loader.
>>
>> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Patch applied. Thanks.
Sorry, I completly missed Giovanni's message. Good work!
Quentin
^ permalink raw reply
* [BUG] crypto: atmel-aes - erro when compiling with VERBOSE_DEBUG enable
From: levent demir @ 2016-09-13 15:09 UTC (permalink / raw)
To: linux-crypto; +Cc: Cyrille Pitchen
Hello,
if you enable VERBOSE_DEBUG and compile you will have the following
error :
drivers/crypto/atmel-aes.c:323:5: error: too few arguments to function
'atmel_aes_reg_name'
atmel_aes_reg_name(offset, tmp));
^
include/linux/device.h:1306:41: note: in definition of macro 'dev_vdbg'
dev_printk(KERN_DEBUG, dev, format, ##arg); \
^
drivers/crypto/atmel-aes.c:205:20: note: declared here
static const char *atmel_aes_reg_name(u32 offset, char *tmp, size_t sz)
Indeed, in atmel_aes_write function the call to atmel_aes_reg_name
contains only two arguments instead of 3 :
atmel_aes_reg_name(offset, tmp));
To fix it, one has to only add the size of tmp as third argument :
atmel_aes_reg_name(offset, tmp, sizeof(tmp)));
--- atmel-aes.c 2016-09-13 17:01:11.199014981 +0200
+++ atmel-aes-fixed.c 2016-09-13 17:01:54.056389455 +0200
@@ -317,7 +317,7 @@
char tmp[16];
dev_vdbg(dd->dev, "write 0x%08x into %s\n", value,
- atmel_aes_reg_name(offset, tmp));
+ atmel_aes_reg_name(offset, tmp, sizeof(tmp)));
}
#endif /* VERBOSE_DEBUG */
^ permalink raw reply
* Re: [PATCH] hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h
From: Michael Ellerman @ 2016-09-14 1:54 UTC (permalink / raw)
To: Herbert Xu, PrasannaKumar Muralidharan
Cc: olof, linuxppc-dev, linux-crypto, mpm
In-Reply-To: <20160913123919.GA31835@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Sep 06, 2016 at 01:58:39PM +0530, PrasannaKumar Muralidharan wrote:
>> Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.
>>
>> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
>
> Patch applied. Thanks.
Oops I merged it too, my bad.
Hopefully git will work out the resolution.
cheers
^ permalink raw reply
* Re: [PATCH] crypto: squash lines for simple wrapper functions
From: Masahiro Yamada @ 2016-09-14 2:10 UTC (permalink / raw)
To: Joe Perches
Cc: linux-crypto, Herbert Xu, Linux Kernel Mailing List,
David S. Miller
In-Reply-To: <1473709457.11006.31.camel@perches.com>
Hi Joe,
2016-09-13 4:44 GMT+09:00 Joe Perches <joe@perches.com>:
> On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
>> Remove unneeded variables and assignments.
>
> Was this found by visual inspection or some tool?
>
> If it's via a tool, it's good to mention that in the changelog.
I used Coccinelle, but I did not mention it
in case somebody may say "then, please provide your semantic patch".
As a Coccinelle beginner, I do not want to expose my stupid semantic patch.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH] crypto: squash lines for simple wrapper functions
From: Joe Perches @ 2016-09-14 2:29 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-crypto, Herbert Xu, Linux Kernel Mailing List,
David S. Miller
In-Reply-To: <CAK7LNAQs2KverOhd2rcG96=fZzsE3M5yfkZJ2ojdTU0Xvunb-Q@mail.gmail.com>
On Wed, 2016-09-14 at 11:10 +0900, Masahiro Yamada wrote:
> 2016-09-13 4:44 GMT+09:00 Joe Perches <joe@perches.com>:
> > On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
> > > Remove unneeded variables and assignments.
> > Was this found by visual inspection or some tool?
> > If it's via a tool, it's good to mention that in the changelog.
> I used Coccinelle, but I did not mention it
> in case somebody may say "then, please provide your semantic patch".
> As a Coccinelle beginner, I do not want to expose my stupid semantic patch.
If you get it "exposed", you'd likely learn something from others
that would give a few suggestions/tips on how to improve it.
^ permalink raw reply
* [PATCH RESEND] crypto: doc - fix documentation for bulk registration functions
From: Eric Biggers @ 2016-09-14 18:56 UTC (permalink / raw)
To: herbert; +Cc: davem, linux-crypto, linux-doc, Eric Biggers
Update the documentation for crypto_register_algs() and
crypto_unregister_algs() to match the actual behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
Documentation/DocBook/crypto-API.tmpl | 38 ++++++++++++++++++++++++-----------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl
index fb2a152..088b79c 100644
--- a/Documentation/DocBook/crypto-API.tmpl
+++ b/Documentation/DocBook/crypto-API.tmpl
@@ -797,7 +797,8 @@ kernel crypto API | Caller
include/linux/crypto.h and their definition can be seen below.
The former function registers a single transformation, while
the latter works on an array of transformation descriptions.
- The latter is useful when registering transformations in bulk.
+ The latter is useful when registering transformations in bulk,
+ for example when a driver implements multiple transformations.
</para>
<programlisting>
@@ -822,18 +823,31 @@ kernel crypto API | Caller
</para>
<para>
- The bulk registration / unregistration functions require
- that struct crypto_alg is an array of count size. These
- functions simply loop over that array and register /
- unregister each individual algorithm. If an error occurs,
- the loop is terminated at the offending algorithm definition.
- That means, the algorithms prior to the offending algorithm
- are successfully registered. Note, the caller has no way of
- knowing which cipher implementations have successfully
- registered. If this is important to know, the caller should
- loop through the different implementations using the single
- instance *_alg functions for each individual implementation.
+ The bulk registration/unregistration functions
+ register/unregister each transformation in the given array of
+ length count. They handle errors as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ crypto_register_algs() succeeds if and only if it
+ successfully registers all the given transformations. If an
+ error occurs partway through, then it rolls back successful
+ registrations before returning the error code. Note that if
+ a driver needs to handle registration errors for individual
+ transformations, then it will need to use the non-bulk
+ function crypto_register_alg() instead.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ crypto_unregister_algs() tries to unregister all the given
+ transformations, continuing on error. It logs errors and
+ always returns zero.
+ </para>
+ </listitem>
+ </itemizedlist>
+
</sect1>
<sect1><title>Single-Block Symmetric Ciphers [CIPHER]</title>
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: CONFIG_FIPS without module loading support?
From: NTU @ 2016-09-15 0:18 UTC (permalink / raw)
To: linux-crypto
In-Reply-To: <20160902142208.GA12938@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
Hello,
I've never written a patch before to the official kernel mailing list
(that I remember) so please forgive me if I didn't send this in
properly. I've generated this using git format-patch HEAD~ --stdout &>
kconfig_fix_for_fips.patch and have attached the file in this email,
gathering as much as I could from the Documentation/SubmittingPatches
page.
Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
must be enabled if FIPS is selected, but in the dependencies for FIPS,
if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
enabled. Which one is true?
Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
more of the DRBG types must be selected. If this is indeed true,
shouldn't the options within CRYPTO_DRBG_MENU be converted to
choice/endchoice versus just booleans? One selection for
CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
for both? Should I submit patches for these as well,
feedback/thoughts?
Thank you!
Alec Ari
[-- Attachment #2: kconfig_fix_for_fips.patch --]
[-- Type: text/x-patch, Size: 1029 bytes --]
From 3f6b786edef09042ff78bc7b4d61fc5a8f8cf657 Mon Sep 17 00:00:00 2001
From: Alec Ari <neotheuser@gmail.com>
Date: Wed, 14 Sep 2016 18:52:04 -0500
Subject: [PATCH] Fix Kconfig dependencies for FIPS
Currently FIPS depends on MODULE_SIG, even if MODULES is disabled.
This change allows the enabling of FIPS without support for modules.
If module loading support is enabled, only then does
FIPS require MODULE_SIG.
Signed-off-by: Alec Ari <neotheuser@gmail.com>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..fd28805 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -24,7 +24,7 @@ comment "Crypto core or helper"
config CRYPTO_FIPS
bool "FIPS 200 compliance"
depends on (CRYPTO_ANSI_CPRNG || CRYPTO_DRBG) && !CRYPTO_MANAGER_DISABLE_TESTS
- depends on MODULE_SIG
+ depends on (MODULE_SIG || !MODULES)
help
This options enables the fips boot option which is
required if you want to system to operate in a FIPS 200
--
2.7.3
^ permalink raw reply related
* [PATCH -next] crypto: omap-des - fix error return code in omap_des_probe()
From: Wei Yongjun @ 2016-09-15 3:27 UTC (permalink / raw)
To: Herbert Xu, Baolin; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -ENOMEM from the crypto_engine_alloc_init()
error handling case instead of 0, as done elsewhere in this function.
Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto
engine framework")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/omap-des.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 2b20d96..a6f6553 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -1081,8 +1081,10 @@ static int omap_des_probe(struct platform_device *pdev)
/* Initialize des crypto engine */
dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
+ if (!dd->engine) {
+ err = -ENOMEM;
goto err_engine;
+ }
dd->engine->prepare_cipher_request = omap_des_prepare_req;
dd->engine->cipher_one_request = omap_des_crypt_req;
^ permalink raw reply related
* [PATCH -next] crypto: omap-aes - fix error return code in omap_aes_probe()
From: Wei Yongjun @ 2016-09-15 3:27 UTC (permalink / raw)
To: Herbert Xu, Baolin Wang; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -ENOMEM from the crypto_engine_alloc_init()
error handling case instead of 0, as done elsewhere in this function.
Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/omap-aes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 2033769..fe32dd9 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1215,8 +1215,10 @@ static int omap_aes_probe(struct platform_device *pdev)
/* Initialize crypto engine */
dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
+ if (!dd->engine) {
+ err = -ENOMEM;
goto err_engine;
+ }
dd->engine->prepare_cipher_request = omap_aes_prepare_req;
dd->engine->cipher_one_request = omap_aes_crypt_req;
^ permalink raw reply related
* [PATCH -next] crypto: ccp - use kmem_cache_zalloc instead of kmem_cache_alloc/memset
From: Wei Yongjun @ 2016-09-15 3:28 UTC (permalink / raw)
To: Tom Lendacky, Gary Hook, Herbert Xu; +Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
Using kmem_cache_zalloc() instead of kmem_cache_alloc() and memset().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/crypto/ccp/ccp-dmaengine.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dmaengine.c b/drivers/crypto/ccp/ccp-dmaengine.c
index ded26f4..2e5a05c 100644
--- a/drivers/crypto/ccp/ccp-dmaengine.c
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -299,12 +299,10 @@ static struct ccp_dma_desc *ccp_alloc_dma_desc(struct ccp_dma_chan *chan,
{
struct ccp_dma_desc *desc;
- desc = kmem_cache_alloc(chan->ccp->dma_desc_cache, GFP_NOWAIT);
+ desc = kmem_cache_zalloc(chan->ccp->dma_desc_cache, GFP_NOWAIT);
if (!desc)
return NULL;
- memset(desc, 0, sizeof(*desc));
-
dma_async_tx_descriptor_init(&desc->tx_desc, &chan->dma_chan);
desc->tx_desc.flags = flags;
desc->tx_desc.tx_submit = ccp_tx_submit;
^ permalink raw reply related
* Re: CONFIG_FIPS without module loading support?
From: Stephan Mueller @ 2016-09-15 4:58 UTC (permalink / raw)
To: NTU; +Cc: linux-crypto
In-Reply-To: <CAM5Ud7OVvjh1WirzLh9YGzTqQn8qG8mNMe9+0rC7Q7E-0K7Yqg@mail.gmail.com>
Am Mittwoch, 14. September 2016, 19:18:43 CEST schrieb NTU:
Hi NTU,
> Hello,
>
> I've never written a patch before to the official kernel mailing list
> (that I remember) so please forgive me if I didn't send this in
> properly. I've generated this using git format-patch HEAD~ --stdout &>
> kconfig_fix_for_fips.patch and have attached the file in this email,
> gathering as much as I could from the Documentation/SubmittingPatches
> page.
Please read Documentation/SubmittingPatches
>
> Few more things, in the help option for CRYPTO_ANSI_CPRNG, it says it
> must be enabled if FIPS is selected, but in the dependencies for FIPS,
> if DRBG is selected, then CRYPTO_ANSI_CPRNG doesn't need to be
> enabled. Which one is true?
The latter one. The X9.31 DRNG is not approved in FIPS mode any more.
>
> Secondly, in the help option for CRYPTO_DRBG_MENU, it says that one or
> more of the DRBG types must be selected. If this is indeed true,
> shouldn't the options within CRYPTO_DRBG_MENU be converted to
> choice/endchoice versus just booleans? One selection for
> CRYPTO_DRBG_HASH, another for CRYPTO_DRBG_CTR, and then a third option
> for both? Should I submit patches for these as well,
> feedback/thoughts?
Not sure what you want to gain from it. All that the booleans do is to mark
which types of DRBG are to be compliled. The selector whether the DRBG is
compiled at all is CRYPTO_DRBG.
Ciao
Stephan
^ permalink raw reply
* [RFC] revamp fips_allowed flag
From: Stephan Mueller @ 2016-09-15 5:35 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
Hi Herbert,
The fips_allowed flag in testmgr.c shall prevent the use of "non-approved"
ciphers in FIPS mode.
With the current code, the fips_allowed flag is bound to a name a specific
cipher is referenced with. With the advent of more complex cipher string names
that can be used (for example, consider names like
"seqiv(rfc4106(gcm_base(ctr-aes-s390,ghash-generic)))", the authenc ciphers
with the two components or even the recently added pkcspad1 algorithm), it
seems that the approach in testmgr.c reached its limits. Lately more and more
entries in the alg_test_descs array were added purely to have the fips_allowed
flag set.
Wouldn't it be more prudent to move that flag into the crypto_alg and
crypto_template data structures so that the flag is checked during the
crypto_register_* functions? I.e. if the flag is not set and the FIPS mode is
enabled, the cipher is simply not registered?
With that, suggestion, the fips_allowed flag is now decoupled from the cipher
name. Complex cipher strings would now not be falsely treated as non-approved
ciphers any more.
Ciao
Stephan
--
atsec information security GmbH, Steinstraße 70, 81667 München, Germany
P: +49 89 442 49 830 - F: +49 89 442 49 831
M: +49 172 216 55 78 - HRB: 129439 (Amtsgericht München)
US: +1 949 545 4096
GF: Salvatore la Pietra, Staffan Persson
atsec it security news blog - atsec-information-security.blogspot.com
^ permalink raw reply
* Re: [RFC] revamp fips_allowed flag
From: Herbert Xu @ 2016-09-15 5:58 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <1818375.56xtGUSNII@tauon.atsec.com>
On Thu, Sep 15, 2016 at 07:35:43AM +0200, Stephan Mueller wrote:
>
> Wouldn't it be more prudent to move that flag into the crypto_alg and
> crypto_template data structures so that the flag is checked during the
> crypto_register_* functions? I.e. if the flag is not set and the FIPS mode is
> enabled, the cipher is simply not registered?
The problem with that is then if you have 10 implementations of a
given algorithm you'd have to change 10 places to modify its FIPS
status.
Where's the pain point here? For cases like seqiv where you want to
say if X is FIPS-allowed then so is seqiv(X) we can certainly add
some code to testmgr to cater for that instead of listing them
individually.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] revamp fips_allowed flag
From: Stephan Mueller @ 2016-09-15 6:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160915055808.GA14688@gondor.apana.org.au>
Am Donnerstag, 15. September 2016, 13:58:08 CEST schrieb Herbert Xu:
Hi Herbert,
> Where's the pain point here? For cases like seqiv where you want to
> say if X is FIPS-allowed then so is seqiv(X) we can certainly add
> some code to testmgr to cater for that instead of listing them
> individually.
Where shall we draw the line here? Shall that be only for authenc, or seqiv?
Or shall we also consider rfc4106 too, knowing that there are implementations
which provide a full rfc4106 GCM combo (x86 for example). What about the
current pkcspad1 template where we could expect that there may be entire HW
implementations with that?
Ciao
Stephan
^ permalink raw reply
* Re: [RFC] revamp fips_allowed flag
From: Herbert Xu @ 2016-09-15 6:26 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <2606890.Z1PDhBGeZR@tauon.atsec.com>
On Thu, Sep 15, 2016 at 08:23:05AM +0200, Stephan Mueller wrote:
>
> Where shall we draw the line here? Shall that be only for authenc, or seqiv?
> Or shall we also consider rfc4106 too, knowing that there are implementations
> which provide a full rfc4106 GCM combo (x86 for example). What about the
> current pkcspad1 template where we could expect that there may be entire HW
> implementations with that?
That's something that only you can tell us :)
For such templates we could move that info into the generic
template implementation code and have them declare themselves
as such that for any X if X is FIPS allowed then so is T(X).
This info can then be used in testmgr.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCHv3 00/11] crypto: omap HW crypto fixes
From: Tero Kristo @ 2016-09-15 9:12 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <20160913123849.GA31890@gondor.apana.org.au>
On 13/09/16 15:38, Herbert Xu wrote:
> On Thu, Aug 04, 2016 at 01:28:35PM +0300, Tero Kristo wrote:
>> Hi,
>>
>> This revision took quite a bit time to craft due to the rework needed
>> for sham buffer handling and export/import. I ended up implementing
>> a flush functionality for draining out the sham buffer when doing
>> export/import; just shrinking the buffer to sufficiently small size
>> impacted the performance with small data chunks too much so I dropped
>> this approach.
>>
>> The series also fixes a couple of existing issues with omap2/omap3
>> hardware acceleration, I ran a full boot test / crypto manager
>> test suite on all boards accessible to me now.
>>
>> Based on top of latest mainline, which is somewhere before 4.8-rc1
>> as of writing this, I am unable to rebase the series during the next
>> three weeks so wanted to get this out now. Targeted for 4.9 merge
>> window, some fixes could be picked up earlier though if needed.
>
> I have applied patches 1,4-5,7-11. Some of them didn't apply
> cleanly so please check the result in my tree.
>
> Thanks,
>
Thanks Herbert,
I just gave a trial for your branch, and seems to be working for me.
Also checked the patches you applied and they seem fine also.
I have also a new version of the sha buffer handling and export/import
available now, but need to cleanup it quite a bit, and figure out how to
split the patch properly.
drivers/crypto/omap-sham.c | 532
++++++++++++++++++++++++++-------------------
... It now uses sg for xmitting data where possible, and avoids the need
for a large internal buffer. The buffer size is also now properly
configurable, which can be used to overcome the performance issues if
needed (this however, requires the max statesize hack within the
crypto/ahash.c file, but thats fine.) I'll hopefully post this out maybe
tomorrow, but its going to be targeted for 4.10 I believe due to the
(ahem, rather) intrusive changes.
-Tero
^ permalink raw reply
* Re: [PATCHv3 06/11] crypto: omap-des: Fix support for unequal lengths
From: Tero Kristo @ 2016-09-15 9:15 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel, Lokesh Vutla
In-Reply-To: <20160913093506.GA30561@gondor.apana.org.au>
On 13/09/16 12:35, Herbert Xu wrote:
> On Thu, Aug 04, 2016 at 01:28:41PM +0300, Tero Kristo wrote:
>> From: Lokesh Vutla <a0131933@ti.com>
>>
>> For cases where total length of an input SGs is not same as
>> length of the input data for encryption, omap-des driver
>> crashes. This happens in the case when IPsec is trying to use
>> omap-des driver.
>>
>> To avoid this, we copy all the pages from the input SG list
>> into a contiguous buffer and prepare a single element SG list
>> for this buffer with length as the total bytes to crypt, which is
>> similar thing that is done in case of unaligned lengths.
>
> Ugh, that means copying every single packet, right?
>
> So if it's just the SG list that's the problem, why don't you
> copy that instead? That is, allocate a new SG list and set it
> up so that there is no excess data.
>
> Cheers,
>
I'll take a look at this. I have this kind of solution in place for the
re-worked SHA driver, so can probably re-use it here.
-Tero
^ permalink raw reply
* crypto-caamhash: Fine-tuning for several function implementations
From: SF Markus Elfring @ 2016-09-15 14:36 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <566ABCD9.1060404@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 16:27:23 +0200
Some update suggestions were taken into account
from static source code analysis.
Markus Elfring (6):
Use kmalloc_array() in ahash_setkey()
Rename jump labels in ahash_setkey()
Rename a jump label in five functions
Return a value directly in caam_hash_cra_init()
Delete an unnecessary initialisation in seven functions
Move common error handling code in two functions
drivers/crypto/caam/caamhash.c | 111 +++++++++++++++++++----------------------
1 file changed, 52 insertions(+), 59 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH 1/6] crypto-caamhash: Use kmalloc_array() in ahash_setkey()
From: SF Markus Elfring @ 2016-09-15 14:40 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 11:20:09 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data type by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 9d7fc9e..f19df8f 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -525,8 +525,9 @@ static int ahash_setkey(struct crypto_ahash *ahash,
#endif
if (keylen > blocksize) {
- hashed_key = kmalloc(sizeof(u8) * digestsize, GFP_KERNEL |
- GFP_DMA);
+ hashed_key = kmalloc_array(digestsize,
+ sizeof(*hashed_key),
+ GFP_KERNEL | GFP_DMA);
if (!hashed_key)
return -ENOMEM;
ret = hash_digest_key(ctx, key, &keylen, hashed_key,
--
2.10.0
^ permalink raw reply related
* [PATCH 2/6] crypto-caamhash: Rename jump labels in ahash_setkey()
From: SF Markus Elfring @ 2016-09-15 14:41 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 13:54:49 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index f19df8f..6017470 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -533,7 +533,7 @@ static int ahash_setkey(struct crypto_ahash *ahash,
ret = hash_digest_key(ctx, key, &keylen, hashed_key,
digestsize);
if (ret)
- goto badkey;
+ goto bad_free_key;
key = hashed_key;
}
@@ -551,14 +551,14 @@ static int ahash_setkey(struct crypto_ahash *ahash,
ret = gen_split_hash_key(ctx, key, keylen);
if (ret)
- goto badkey;
+ goto bad_free_key;
ctx->key_dma = dma_map_single(jrdev, ctx->key, ctx->split_key_pad_len,
DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, ctx->key_dma)) {
dev_err(jrdev, "unable to map key i/o memory\n");
ret = -ENOMEM;
- goto map_err;
+ goto error_free_key;
}
#ifdef DEBUG
print_hex_dump(KERN_ERR, "ctx.key@"__stringify(__LINE__)": ",
@@ -571,11 +571,10 @@ static int ahash_setkey(struct crypto_ahash *ahash,
dma_unmap_single(jrdev, ctx->key_dma, ctx->split_key_pad_len,
DMA_TO_DEVICE);
}
-
-map_err:
+ error_free_key:
kfree(hashed_key);
return ret;
-badkey:
+ bad_free_key:
kfree(hashed_key);
crypto_ahash_set_flags(ahash, CRYPTO_TFM_RES_BAD_KEY_LEN);
return -EINVAL;
--
2.10.0
^ permalink raw reply related
* [PATCH 3/6] crypto-caamhash: Rename a jump label in five functions
From: SF Markus Elfring @ 2016-09-15 14:42 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 14:43:38 +0200
Adjust jump labels according to the current Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 49 +++++++++++++++++++-----------------------
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 6017470..933252f 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -889,7 +889,7 @@ static int ahash_update_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_BIDIRECTIONAL);
if (ret)
- goto err;
+ goto unmap_ctx;
state->buf_dma = try_buf_map_to_sec4_sg(jrdev,
edesc->sec4_sg + 1,
@@ -919,7 +919,7 @@ static int ahash_update_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len +
@@ -935,7 +935,7 @@ static int ahash_update_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_bi, req);
if (ret)
- goto err;
+ goto unmap_ctx;
ret = -EINPROGRESS;
} else if (*next_buflen) {
@@ -953,8 +953,7 @@ static int ahash_update_ctx(struct ahash_request *req)
#endif
return ret;
-
- err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_BIDIRECTIONAL);
kfree(edesc);
return ret;
@@ -996,7 +995,7 @@ static int ahash_final_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_TO_DEVICE);
if (ret)
- goto err;
+ goto unmap_ctx;
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
buf, state->buf_dma, buflen,
@@ -1009,7 +1008,7 @@ static int ahash_final_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
append_seq_in_ptr(desc, edesc->sec4_sg_dma, ctx->ctx_len + buflen,
@@ -1020,7 +1019,7 @@ static int ahash_final_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
#ifdef DEBUG
@@ -1030,11 +1029,10 @@ static int ahash_final_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
if (ret)
- goto err;
+ goto unmap_ctx;
return -EINPROGRESS;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, digestsize, DMA_FROM_DEVICE);
kfree(edesc);
return ret;
@@ -1094,7 +1092,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
ret = ctx_map_to_sec4_sg(desc, jrdev, state, ctx->ctx_len,
edesc->sec4_sg, DMA_TO_DEVICE);
if (ret)
- goto err;
+ goto unmap_ctx;
state->buf_dma = try_buf_map_to_sec4_sg(jrdev, edesc->sec4_sg + 1,
buf, state->buf_dma, buflen,
@@ -1104,14 +1102,14 @@ static int ahash_finup_ctx(struct ahash_request *req)
sec4_sg_src_index, ctx->ctx_len + buflen,
req->nbytes);
if (ret)
- goto err;
+ goto unmap_ctx;
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
#ifdef DEBUG
@@ -1121,11 +1119,10 @@ static int ahash_finup_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
if (ret)
- goto err;
+ goto unmap_ctx;
return -EINPROGRESS;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, digestsize, DMA_FROM_DEVICE);
kfree(edesc);
return ret;
@@ -1350,14 +1347,14 @@ static int ahash_update_no_ctx(struct ahash_request *req)
if (dma_mapping_error(jrdev, edesc->sec4_sg_dma)) {
dev_err(jrdev, "unable to map S/G table\n");
ret = -ENOMEM;
- goto err;
+ goto unmap_ctx;
}
append_seq_in_ptr(desc, edesc->sec4_sg_dma, to_hash, LDST_SGF);
ret = map_seq_out_ptr_ctx(desc, jrdev, state, ctx->ctx_len);
if (ret)
- goto err;
+ goto unmap_ctx;
#ifdef DEBUG
print_hex_dump(KERN_ERR, "jobdesc@"__stringify(__LINE__)": ",
@@ -1367,7 +1364,7 @@ static int ahash_update_no_ctx(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_dst, req);
if (ret)
- goto err;
+ goto unmap_ctx;
ret = -EINPROGRESS;
state->update = ahash_update_ctx;
@@ -1388,8 +1385,7 @@ static int ahash_update_no_ctx(struct ahash_request *req)
#endif
return ret;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_TO_DEVICE);
kfree(edesc);
return ret;
@@ -1548,7 +1544,7 @@ static int ahash_update_first(struct ahash_request *req)
ret = ahash_edesc_add_src(ctx, edesc, req, mapped_nents, 0, 0,
to_hash);
if (ret)
- goto err;
+ goto unmap_ctx;
if (*next_buflen)
scatterwalk_map_and_copy(next_buf, req->src, to_hash,
@@ -1558,7 +1554,7 @@ static int ahash_update_first(struct ahash_request *req)
ret = map_seq_out_ptr_ctx(desc, jrdev, state, ctx->ctx_len);
if (ret)
- goto err;
+ goto unmap_ctx;
#ifdef DEBUG
print_hex_dump(KERN_ERR, "jobdesc@"__stringify(__LINE__)": ",
@@ -1568,7 +1564,7 @@ static int ahash_update_first(struct ahash_request *req)
ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_dst, req);
if (ret)
- goto err;
+ goto unmap_ctx;
ret = -EINPROGRESS;
state->update = ahash_update_ctx;
@@ -1588,8 +1584,7 @@ static int ahash_update_first(struct ahash_request *req)
#endif
return ret;
-
-err:
+ unmap_ctx:
ahash_unmap_ctx(jrdev, edesc, req, ctx->ctx_len, DMA_TO_DEVICE);
kfree(edesc);
return ret;
--
2.10.0
^ permalink raw reply related
* [PATCH 4/6] crypto-caamhash: Return a value directly in caam_hash_cra_init()
From: SF Markus Elfring @ 2016-09-15 14:43 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 14:56:12 +0200
* Return a value at the end without storing it in an intermediate variable.
* Delete the local variable "ret" which became unnecessary with
this refactoring.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 933252f..b1dbc53 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1846,7 +1846,6 @@ static int caam_hash_cra_init(struct crypto_tfm *tfm)
HASH_MSG_LEN + SHA256_DIGEST_SIZE,
HASH_MSG_LEN + 64,
HASH_MSG_LEN + SHA512_DIGEST_SIZE };
- int ret = 0;
/*
* Get a Job ring from Job Ring driver to ensure in-order
@@ -1866,10 +1865,7 @@ static int caam_hash_cra_init(struct crypto_tfm *tfm)
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
sizeof(struct caam_hash_state));
-
- ret = ahash_set_sh_desc(ahash);
-
- return ret;
+ return ahash_set_sh_desc(ahash);
}
static void caam_hash_cra_exit(struct crypto_tfm *tfm)
--
2.10.0
^ permalink raw reply related
* [PATCH 5/6] crypto-caamhash: Delete an unnecessary initialisation in seven functions
From: SF Markus Elfring @ 2016-09-15 14:44 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 15:24:02 +0200
The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index b1dbc53..adb8b19 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -440,7 +440,7 @@ static int hash_digest_key(struct caam_hash_ctx *ctx, const u8 *key_in,
u32 *desc;
struct split_key_result result;
dma_addr_t src_dma, dst_dma;
- int ret = 0;
+ int ret;
desc = kmalloc(CAAM_CMD_SZ * 8 + CAAM_PTR_SZ * 2, GFP_KERNEL | GFP_DMA);
if (!desc) {
@@ -517,7 +517,7 @@ static int ahash_setkey(struct crypto_ahash *ahash,
struct device *jrdev = ctx->jrdev;
int blocksize = crypto_tfm_alg_blocksize(&ahash->base);
int digestsize = crypto_ahash_digestsize(ahash);
- int ret = 0;
+ int ret;
u8 *hashed_key = NULL;
#ifdef DEBUG
@@ -975,7 +975,7 @@ static int ahash_final_ctx(struct ahash_request *req)
int sec4_sg_bytes, sec4_sg_src_index;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
sec4_sg_src_index = 1 + (buflen ? 1 : 0);
sec4_sg_bytes = sec4_sg_src_index * sizeof(struct sec4_sg_entry);
@@ -1055,7 +1055,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
int src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1139,7 +1139,7 @@ static int ahash_digest(struct ahash_request *req)
int digestsize = crypto_ahash_digestsize(ahash);
int src_nents, mapped_nents;
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
@@ -1218,7 +1218,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
u32 *desc;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
/* allocate space for base edesc and hw desc commands, link tables */
edesc = ahash_edesc_alloc(ctx, 0, ctx->sh_desc_digest,
@@ -1408,7 +1408,7 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
int sec4_sg_bytes, sec4_sg_src_index, src_nents, mapped_nents;
int digestsize = crypto_ahash_digestsize(ahash);
struct ahash_edesc *edesc;
- int ret = 0;
+ int ret;
src_nents = sg_nents_for_len(req->src, req->nbytes);
if (src_nents < 0) {
--
2.10.0
^ permalink raw reply related
* [PATCH 6/6] crypto-caamhash: Move common error handling code in two functions
From: SF Markus Elfring @ 2016-09-15 14:45 UTC (permalink / raw)
To: linux-crypto, David S. Miller, Herbert Xu, Labbe Corentin,
Russell King
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 15 Sep 2016 16:00:55 +0200
Move statements for error handling which were identical
in two if branches to the end of these functions.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/crypto/caam/caamhash.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index adb8b19..660dc20 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1231,9 +1231,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
state->buf_dma = dma_map_single(jrdev, buf, buflen, DMA_TO_DEVICE);
if (dma_mapping_error(jrdev, state->buf_dma)) {
dev_err(jrdev, "unable to map src\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
append_seq_in_ptr(desc, state->buf_dma, buflen, 0);
@@ -1242,9 +1240,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
edesc->src_nents = 0;
@@ -1262,6 +1258,11 @@ static int ahash_final_no_ctx(struct ahash_request *req)
}
return ret;
+ unmap:
+ ahash_unmap(jrdev, edesc, req, digestsize);
+ kfree(edesc);
+ return -ENOMEM;
+
}
/* submit ahash update if it the first job descriptor after update */
@@ -1453,18 +1454,14 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
req->nbytes);
if (ret) {
dev_err(jrdev, "unable to map S/G table\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
edesc->dst_dma = map_seq_out_ptr_result(desc, jrdev, req->result,
digestsize);
if (dma_mapping_error(jrdev, edesc->dst_dma)) {
dev_err(jrdev, "unable to map dst\n");
- ahash_unmap(jrdev, edesc, req, digestsize);
- kfree(edesc);
- return -ENOMEM;
+ goto unmap;
}
#ifdef DEBUG
@@ -1481,6 +1478,11 @@ static int ahash_finup_no_ctx(struct ahash_request *req)
}
return ret;
+ unmap:
+ ahash_unmap(jrdev, edesc, req, digestsize);
+ kfree(edesc);
+ return -ENOMEM;
+
}
/* submit first update job descriptor after init */
--
2.10.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox