* [PATCH v3 2/8] dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
From: Romain Perier @ 2016-09-16 10:08 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160916100856.31727-1-romain.perier@free-electrons.com>
This commits add missing fields in the documentation that are used
by the new device variant. It also includes DT example to show how
the variant should be used.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Documentation/devicetree/bindings/rng/omap_rng.txt | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt
index 6a62acd..4714772 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ b/Documentation/devicetree/bindings/rng/omap_rng.txt
@@ -1,4 +1,4 @@
-OMAP SoC HWRNG Module
+OMAP SoC and Inside-Secure HWRNG Module
Required properties:
@@ -6,11 +6,13 @@ Required properties:
RNG versions:
- "ti,omap2-rng" for OMAP2.
- "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+ - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block
Note that these two versions are incompatible.
- ti,hwmods: Name of the hwmod associated with the RNG module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt number for the RNG module.
- Only used for "ti,omap4-rng".
+ Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
+- clocks: the trng clock source
Example:
/* AM335x */
@@ -20,3 +22,11 @@ rng: rng@48310000 {
reg = <0x48310000 0x2000>;
interrupts = <111>;
};
+
+/* SafeXcel IP-76 */
+trng: rng@f2760000 {
+ compatible = "inside-secure,safexcel-eip76";
+ reg = <0xf2760000 0x7d>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 25>;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/8] dt-bindings: Add vendor prefix for INSIDE Secure
From: Romain Perier @ 2016-09-16 10:08 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160916100856.31727-1-romain.perier@free-electrons.com>
This commits adds a vendor for the company INSIDE Secure.
See https://www.insidesecure.com, for more details.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..6a5e872 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -132,6 +132,7 @@ infineon Infineon Technologies
inforce Inforce Computing
ingenic Ingenic Semiconductor
innolux Innolux Corporation
+inside-secure INSIDE Secure
intel Intel Corporation
intercontrol Inter Control Group
invensense InvenSense Inc.
--
2.9.3
^ permalink raw reply related
* [PATCH v3 0/8] Add support for SafeXcel IP-76 to OMAP RNG
From: Romain Perier @ 2016-09-16 10:08 UTC (permalink / raw)
To: dsaxena, mpm, Herbert Xu
Cc: Gregory Clement, Thomas Petazzoni, Romain Perier, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
The driver omap-rng has a lot of similarity with the IP block SafeXcel
IP-76. A lot of registers are the same and the way that the driver works
is very closed the description of the TRNG EIP76 in its datasheet.
This series refactorize the driver, add support for generating bigger
output random data and add a device variant for SafeXcel IP-76, found
in Armada 8K.
Romain Perier (8):
dt-bindings: Add vendor prefix for INSIDE Secure
dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
hwrng: omap - Switch to non-obsolete read API implementation
hwrng: omap - Remove global definition of hwrng
hwrng: omap - Add support for 128-bit output of data
hwrng: omap - Don't prefix the probe message with OMAP
hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
arm64: dts: marvell: add TRNG description for Armada 8K CP
Documentation/devicetree/bindings/rng/omap_rng.txt | 14 +-
.../devicetree/bindings/vendor-prefixes.txt | 1 +
.../boot/dts/marvell/armada-cp110-master.dtsi | 8 +
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 8 +
drivers/char/hw_random/Kconfig | 2 +-
drivers/char/hw_random/omap-rng.c | 162 ++++++++++++++++-----
6 files changed, 152 insertions(+), 43 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH v2 3/8] hwrng: omap - Switch to non-obsolete read API implementation
From: Romain Perier @ 2016-09-16 10:11 UTC (permalink / raw)
To: Herbert Xu
Cc: dsaxena, mpm, Gregory Clement, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160913094825.GA30645@gondor.apana.org.au>
Hi,
Le 13/09/2016 11:48, Herbert Xu a écrit :
> On Wed, Sep 07, 2016 at 05:57:38PM +0200, Romain Perier wrote:
>> +
>> +static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
>> + bool wait)
>> {
>> struct omap_rng_dev *priv;
>> - int data, i;
>>
>> priv = (struct omap_rng_dev *)rng->priv;
>>
>> - for (i = 0; i < 20; i++) {
>> - data = priv->pdata->data_present(priv);
>> - if (data || !wait)
>> - break;
>> - /* RNG produces data fast enough (2+ MBit/sec, even
>> - * during "rngtest" loads, that these delays don't
>> - * seem to trigger. We *could* use the RNG IRQ, but
>> - * that'd be higher overhead ... so why bother?
>> - */
>> - udelay(10);
>
> So in the wait case you're changing the driver's behaviour. Instead
> of waiting for 1us you'll now wait for 1s if there is no data. Is
> this what really what you want?
>
> Cheers,
>
Mhhh, you're right, in this specific case it will add more latency...
with busy loop, on average, 20 retries will be enough to have data...
Thanks!
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] crypto: caam - fix sg dump
From: Catalin Vasile @ 2016-09-16 9:06 UTC (permalink / raw)
To: linux-crypto
Cc: linux-crypto-owner, horia.geanta, alexandru.porosanu,
Catalin Vasile
Ensure scatterlists have a virtual memory mapping before dumping.
Signed-off-by: Catalin Vasile <cata.vasile@nxp.com>
---
drivers/crypto/caam/caamalg.c | 65 +++++++++++++++++++++++++++++++++----------
1 file changed, 50 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 6dc5971..49f1ea7 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -111,6 +111,41 @@
#else
#define debug(format, arg...)
#endif
+
+#ifdef DEBUG
+#include <linux/highmem.h>
+
+static void dbg_dump_sg(const char *level, const char *prefix_str,
+ int prefix_type, int rowsize, int groupsize,
+ struct scatterlist *sg, size_t tlen, bool ascii)
+{
+ struct scatterlist *it;
+ size_t len;
+ void *buf;
+
+ for (it = sg; it != NULL && tlen > 0 ; it = sg_next(sg)) {
+ /*
+ * make sure the scatterlist's page
+ * has a valid virtual memory mapping
+ */
+ buf = kmap(sg_page(it));
+
+ len = min(tlen, it->length);
+ print_hex_dump(level, prefix_str, prefix_type, rowsize,
+ groupsize, sg_virt(it), len, ascii);
+ tlen -= len;
+
+ kunmap(sg_page(it));
+ }
+}
+#else
+static void dbg_dump_sg(const char *level, const char *prefix_str,
+ int prefix_type, int rowsize, int groupsize,
+ struct scatterlist *sg, size_t tlen, bool ascii)
+{
+}
+#endif
+
static struct list_head alg_list;
struct caam_alg_entry {
@@ -1984,9 +2019,9 @@ static void ablkcipher_encrypt_done(struct device *jrdev, u32 *desc, u32 err,
print_hex_dump(KERN_ERR, "dstiv @"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->info,
edesc->src_nents > 1 ? 100 : ivsize, 1);
- print_hex_dump(KERN_ERR, "dst @"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
- edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
+ dbg_dump_sg(KERN_ERR, "dst @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, req->dst,
+ edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
#endif
ablkcipher_unmap(jrdev, edesc, req);
@@ -2016,9 +2051,9 @@ static void ablkcipher_decrypt_done(struct device *jrdev, u32 *desc, u32 err,
print_hex_dump(KERN_ERR, "dstiv @"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->info,
ivsize, 1);
- print_hex_dump(KERN_ERR, "dst @"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
- edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
+ dbg_dump_sg(KERN_ERR, "dst @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, req->dst,
+ edesc->dst_nents > 1 ? 100 : req->nbytes, 1);
#endif
ablkcipher_unmap(jrdev, edesc, req);
@@ -2176,9 +2211,9 @@ static void init_ablkcipher_job(u32 *sh_desc, dma_addr_t ptr,
print_hex_dump(KERN_ERR, "presciv@"__stringify(__LINE__)": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->info,
ivsize, 1);
- print_hex_dump(KERN_ERR, "src @"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
- edesc->src_nents ? 100 : req->nbytes, 1);
+ dbg_dump_sg(KERN_ERR, "src @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, req->src,
+ edesc->src_nents ? 100 : req->nbytes, 1);
#endif
len = desc_len(sh_desc);
@@ -2233,9 +2268,9 @@ static void init_ablkcipher_giv_job(u32 *sh_desc, dma_addr_t ptr,
print_hex_dump(KERN_ERR, "presciv@" __stringify(__LINE__) ": ",
DUMP_PREFIX_ADDRESS, 16, 4, req->info,
ivsize, 1);
- print_hex_dump(KERN_ERR, "src @" __stringify(__LINE__) ": ",
- DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
- edesc->src_nents ? 100 : req->nbytes, 1);
+ dbg_dump_sg(KERN_ERR, "src @" __stringify(__LINE__) ": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, req->src,
+ edesc->src_nents ? 100 : req->nbytes, 1);
#endif
len = desc_len(sh_desc);
@@ -2512,9 +2547,9 @@ static int aead_decrypt(struct aead_request *req)
return PTR_ERR(edesc);
#ifdef DEBUG
- print_hex_dump(KERN_ERR, "dec src@"__stringify(__LINE__)": ",
- DUMP_PREFIX_ADDRESS, 16, 4, sg_virt(req->src),
- req->assoclen + req->cryptlen, 1);
+ dbg_dump_sg(KERN_ERR, "dec src@"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, req->src,
+ req->assoclen + req->cryptlen, 1);
#endif
/* Create and submit job descriptor*/
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC] revamp fips_allowed flag
From: Herbert Xu @ 2016-09-16 5:56 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <9465267.bxih8SxCui@tauon.atsec.com>
On Fri, Sep 16, 2016 at 07:42:13AM +0200, Stephan Mueller wrote:
>
> > 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.
>
> I can see that, but I do not believe it makes our life in the testmgr easier.
> The reason is that in a lot of cases, the template parts (read: block chaining
> modes) are moved into implementations. The most notable examples are the x86
> Intel and the S390 CPACF implementations. For those, the template handling
> code is not triggered and thus we still would need testmgr entries with the
> block chaining modes.
That's not what I meant. The template is only responsible for
providing that info to testmgr. The actual rule will then apply
to any cra_name which matches it. That is, if template T says
that it is OK under FIPS, then every algorithm of type T(X) will
be allowed if X is allowed.
> Considering that we now have RSA in the kernel and that we could expect RSA
> implementations in hardware (in fact, we already have them), there is another
> complication: FIPS only allows RSA according to FIPS 186-4 and not according
> to FIPS 186-2 (ok, the main difference is in key gen, which we do not have).
> What I want to say here is that with the more complex style ciphers, it may
> very well be possible that only the respective implementation knows whether it
> is FIPS compliant.
Please give a concrete example.
> Thus, I am still thinking that moving the fips_allowed flag into the structs
> that are evaluated during register time is more helpful. I definitely see that
> this would imply that all, say, AES implementations need that flag. But IMHO
> it is a much cleaner solution, because if the register is rejected, the cipher
> does not show up in /proc/crypto and everybody knows that a particular cipher
> is not in use.
That's crazy. For AES we already have dozens of implementations,
think about the amount of churn that will occur when one AES
implementation is obsoleted by FIPS.
> My particular example is that in one test with FIPS mode enabled,
> seqiv(rfc4106(gcm-base(...))) was successfully loaded and marked as selftest
> passed in /proc/crypto. Yet, an allocation of the test failed with ENOENT.
> Rebooting the system without FIPS mode allowed me to allocate the cipher. As
> there is no test for this particular cipher name in testmgr, I highly suspect
> that the allocation code did not find it because somehow there was no test. In
> any case, it is definitely not clear why that particular cipher name cannot be
> allocated in FIPS mode given the entries in /proc/crypto.
Sounds like our testmgr dealing with FIPS is buggy. It probably
shouldn't mark it as passed.
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-16 5:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160915062629.GA14950@gondor.apana.org.au>
Am Donnerstag, 15. September 2016, 14:26:29 CEST schrieb Herbert Xu:
Hi Herbert,
> 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 :)
Well, as a baseline we can say that:
- with the exception of a few block chaining modes (e.g. xcbc, pcbc, lrw) all
templates are allowed in FIPS mode
- almost all "non-approved" ciphers (i.e those that should not have a
fips_allowed flag) are due to the raw base cipher (i.e. only SHA1/2, AES and
TDES is allowed)
- all compression algos are allowed
>
> 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.
I can see that, but I do not believe it makes our life in the testmgr easier.
The reason is that in a lot of cases, the template parts (read: block chaining
modes) are moved into implementations. The most notable examples are the x86
Intel and the S390 CPACF implementations. For those, the template handling
code is not triggered and thus we still would need testmgr entries with the
block chaining modes.
Considering that we now have RSA in the kernel and that we could expect RSA
implementations in hardware (in fact, we already have them), there is another
complication: FIPS only allows RSA according to FIPS 186-4 and not according
to FIPS 186-2 (ok, the main difference is in key gen, which we do not have).
What I want to say here is that with the more complex style ciphers, it may
very well be possible that only the respective implementation knows whether it
is FIPS compliant.
Thus, I am still thinking that moving the fips_allowed flag into the structs
that are evaluated during register time is more helpful. I definitely see that
this would imply that all, say, AES implementations need that flag. But IMHO
it is a much cleaner solution, because if the register is rejected, the cipher
does not show up in /proc/crypto and everybody knows that a particular cipher
is not in use.
My particular example is that in one test with FIPS mode enabled,
seqiv(rfc4106(gcm-base(...))) was successfully loaded and marked as selftest
passed in /proc/crypto. Yet, an allocation of the test failed with ENOENT.
Rebooting the system without FIPS mode allowed me to allocate the cipher. As
there is no test for this particular cipher name in testmgr, I highly suspect
that the allocation code did not find it because somehow there was no test. In
any case, it is definitely not clear why that particular cipher name cannot be
allocated in FIPS mode given the entries in /proc/crypto.
Ciao
Stephan
^ permalink raw reply
* [PATCH -next] hwrng: geode - fix return value check in mod_init()
From: Wei Yongjun @ 2016-09-16 1:50 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, PrasannaKumar Muralidharan
Cc: Wei Yongjun, linux-geode, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
In case of error, the function devm_ioremap() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should
be replaced with NULL test.
Fixes: 6e9b5e76882c ("hwrng: geode - Migrate to managed API")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/char/hw_random/geode-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/geode-rng.c b/drivers/char/hw_random/geode-rng.c
index 0cae210..e7a2459 100644
--- a/drivers/char/hw_random/geode-rng.c
+++ b/drivers/char/hw_random/geode-rng.c
@@ -95,8 +95,8 @@ static int __init mod_init(void)
return -ENODEV;
mem = devm_ioremap(&pdev->dev, rng_base, 0x58);
- if (IS_ERR(mem))
- return PTR_ERR(mem);
+ if (!mem)
+ return -ENOMEM;
geode_rng.priv = (unsigned long)mem;
pr_info("AMD Geode RNG detected\n");
^ permalink raw reply related
* [PATCH -next] hwrng: amd - Fix return value check in mod_init()
From: Wei Yongjun @ 2016-09-16 1:49 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Corentin LABBE,
PrasannaKumar Muralidharan
Cc: Wei Yongjun, linux-crypto
From: Wei Yongjun <weiyongjun1@huawei.com>
In case of error, the function devm_kzalloc() or devm_ioport_map()
return NULL pointer not ERR_PTR(). The IS_ERR() test in the return
value check should be replaced with NULL test.
Fixes: 31b2a73c9c5f ("hwrng: amd - Migrate to managed API")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/char/hw_random/amd-rng.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 4dbc5aa..4a99ac7 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -149,8 +149,8 @@ static int __init mod_init(void)
return -EIO;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
- if (IS_ERR(priv))
- return PTR_ERR(priv);
+ if (!priv)
+ return -ENOMEM;
if (!devm_request_region(&pdev->dev, pmbase + PMBASE_OFFSET,
PMBASE_SIZE, DRV_NAME)) {
@@ -161,9 +161,9 @@ static int __init mod_init(void)
priv->iobase = devm_ioport_map(&pdev->dev, pmbase + PMBASE_OFFSET,
PMBASE_SIZE);
- if (IS_ERR(priv->iobase)) {
+ if (!priv->iobase) {
pr_err(DRV_NAME "Cannot map ioport\n");
- return PTR_ERR(priv->iobase);
+ return -ENOMEM;
}
amd_rng.priv = (unsigned long)priv;
^ permalink raw reply related
* Re: [PATCH] Fix Kconfig dependencies for FIPS
From: NTU @ 2016-09-15 22:45 UTC (permalink / raw)
To: linux-crypto
In-Reply-To: <CAM5Ud7Ph1LR_8F7Pm9x55B9bozuQL+=6NZfVMjPtTPiDswfUHw@mail.gmail.com>
I hope I got this right, on my screen the first "depends on" line is
incorrectly truncated, hope this will not become problematic..
Alec Ari
^ permalink raw reply
* [PATCH] Fix Kconfig dependencies for FIPS
From: NTU @ 2016-09-15 22:41 UTC (permalink / raw)
To: linux-crypto
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
* Re: CONFIG_FIPS without module loading support?
From: Stephan Mueller @ 2016-09-15 18:31 UTC (permalink / raw)
To: NTU; +Cc: linux-crypto
In-Reply-To: <CAM5Ud7PsjjrR0Ta6RFJbxcxXqVj7aEwzWF__7TEKpxun96NhdQ@mail.gmail.com>
Am Donnerstag, 15. September 2016, 12:06:20 CEST schrieb NTU:
Hi NTU,
> What did I miss from the SubmittingPatches page? Some constructive
The patch should be inline to the email -- see all other patch submissions.
Then, the email subject should be appropriate.
> criticism please? Step 1 is skipped due to the fact I'm using git,
> patch is in proper form. Step 2, I described the patch. 3, it's one
> line, so it cannot be separated. Step 4, checkpatch.pl says it's good.
> The section in 5 confused me a little bit. 6, the patch is plain text.
> 7, it is under 300k (easily.) 8, doing it right now. 9, ok. 10, PATCH
> is included in the subject. 11, it is signed, says signed off at the
> bottom of the comment section. 12 I don't think is applicable to this?
> 13, not applicable again? 14, it is in canonical format, comment lines
> do not exceed 70 characters, it has a marker line, diff output etc. 15
> confused me a little. 16 it is not a series of patches.
>
> If ANSI_CPRNG is not approved anymore for FIPS, the help section
> should be updated then.
>
> As for converting the DRBG booleans to choice, it is so that way users
> cannot have both options disabled, in the case they don't read the
> help for it.
>
> Alec
>
> On Wed, Sep 14, 2016 at 11:58 PM, Stephan Mueller <smueller@chronox.de>
wrote:
> > 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
^ permalink raw reply
* Re: CONFIG_FIPS without module loading support?
From: NTU @ 2016-09-15 17:06 UTC (permalink / raw)
To: linux-crypto
In-Reply-To: <2523179.y8adHMcoDs@tauon.atsec.com>
What did I miss from the SubmittingPatches page? Some constructive
criticism please? Step 1 is skipped due to the fact I'm using git,
patch is in proper form. Step 2, I described the patch. 3, it's one
line, so it cannot be separated. Step 4, checkpatch.pl says it's good.
The section in 5 confused me a little bit. 6, the patch is plain text.
7, it is under 300k (easily.) 8, doing it right now. 9, ok. 10, PATCH
is included in the subject. 11, it is signed, says signed off at the
bottom of the comment section. 12 I don't think is applicable to this?
13, not applicable again? 14, it is in canonical format, comment lines
do not exceed 70 characters, it has a marker line, diff output etc. 15
confused me a little. 16 it is not a series of patches.
If ANSI_CPRNG is not approved anymore for FIPS, the help section
should be updated then.
As for converting the DRBG booleans to choice, it is so that way users
cannot have both options disabled, in the case they don't read the
help for it.
Alec
On Wed, Sep 14, 2016 at 11:58 PM, Stephan Mueller <smueller@chronox.de> wrote:
> 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
* Re: crypto-caamhash: Fine-tuning for several function implementations
From: Horia Geanta Neag @ 2016-09-15 15:30 UTC (permalink / raw)
To: SF Markus Elfring, linux-crypto@vger.kernel.org, David S. Miller,
Herbert Xu, Labbe Corentin, Russell King
Cc: LKML, kernel-janitors@vger.kernel.org, Julia Lawall
In-Reply-To: <970e9e1b-c1dc-eb28-b380-92c15e9b1961@users.sourceforge.net>
On 9/15/2016 5:37 PM, SF Markus Elfring wrote:
> 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(-)
>
Thanks Markus!
For patches 2-6:
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
though headline prefix should be changed to "crypto: caam -"
Horia
^ permalink raw reply
* Re: [PATCH 1/6] crypto-caamhash: Use kmalloc_array() in ahash_setkey()
From: Horia Geanta Neag @ 2016-09-15 15:12 UTC (permalink / raw)
To: SF Markus Elfring, linux-crypto@vger.kernel.org, David S. Miller,
Herbert Xu, Labbe Corentin, Russell King
Cc: LKML, kernel-janitors@vger.kernel.org, Julia Lawall
In-Reply-To: <4e1bc780-fa00-cfc9-c058-240bb899d701@users.sourceforge.net>
On 9/15/2016 5:43 PM, SF Markus Elfring wrote:
> 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);
While correct, instead I would go with kmalloc() and get rid of sizeof(u8).
Horia
^ permalink raw reply
* [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
* [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 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 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 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 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
* 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
* 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
* 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: [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
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