Re: [PATCH] crypto: use list to stage async seeding requests
On Sat, Jun 06, 2015 at 04:16:54AM +0200, Stephan Mueller wrote: > This patch uses a list to track the asynchronous seeding requests until > the nonblocking pool is fully initialized. The random.c is provided with > two API calls: the get_blocking_random_bytes_cb allows the caller to > provide a callback function that is triggered once the nonblocking pool > is initialized. If the nonblocking pool is already initialized at the > time of invocation, the function is a noop. The second API call of > get_blocking_random_bytes_cancel allows the caller to cancel an > outstanding request. > > The previous approach used a waitqueue for maintaining the requests > until the nonblocking pool is initialized. In some circumstances, the > wait can be very long (in the orders of minutes) where the use of > waitqueues is not appropriate. > > The patch also removes the entropy buffer registered with the DRBG > handle in favor of stack variables to hold the seed data. > > CC: Andreas Steffen > CC: Theodore Ts'o > CC: Sandy Harris > Signed-off-by: Stephan Mueller This patch still has many issues with repsect to work cancellation. I've decided to do this myself. I will post the result once I have done some testing. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nios2: Export get_cycles
On Tue, Jun 09, 2015 at 03:19:32PM +1000, Stephen Rothwell wrote: > Hi Herbert, > > On Tue, 9 Jun 2015 12:46:46 +0800 Herbert Xu > wrote: > > > > On Mon, Jun 08, 2015 at 09:31:54PM -0700, Guenter Roeck wrote: > > > > > > nios2 still fails to build with > > > > > > ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined! > > > > It's the only arch that doesn't inline get_cycles and doesn't > > export it. > > > > ---8<--- > > nios2 is the only architecture that does not inline get_cycles > > and does not export it. This breaks crypto as it uses get_cycles > > in a number of modules. > > > > Reported-by: Guenter Roeck > > Signed-off-by: Herbert Xu > > Also added into linux-next today. > > I am assuming that they will turn up in the crypto tree soon(ish). Yes I'll be adding them to cryptodev. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nios2: Export get_cycles
Hi Herbert, On Tue, 9 Jun 2015 12:46:46 +0800 Herbert Xu wrote: > > On Mon, Jun 08, 2015 at 09:31:54PM -0700, Guenter Roeck wrote: > > > > nios2 still fails to build with > > > > ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined! > > It's the only arch that doesn't inline get_cycles and doesn't > export it. > > ---8<--- > nios2 is the only architecture that does not inline get_cycles > and does not export it. This breaks crypto as it uses get_cycles > in a number of modules. > > Reported-by: Guenter Roeck > Signed-off-by: Herbert Xu Also added into linux-next today. I am assuming that they will turn up in the crypto tree soon(ish). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpcAYAwdzMS1.pgp Description: OpenPGP digital signature
nios2: Export get_cycles
On Mon, Jun 08, 2015 at 09:31:54PM -0700, Guenter Roeck wrote:
>
> nios2 still fails to build with
>
> ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined!
It's the only arch that doesn't inline get_cycles and doesn't
export it.
---8<---
nios2 is the only architecture that does not inline get_cycles
and does not export it. This breaks crypto as it uses get_cycles
in a number of modules.
Reported-by: Guenter Roeck
Signed-off-by: Herbert Xu
diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index 7f45474..be186a7 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -8,6 +8,7 @@
* for more details.
*/
+#include
#include
#include
#include
@@ -106,6 +107,7 @@ cycles_t get_cycles(void)
{
return nios2_timer_read(&nios2_cs.cs);
}
+EXPORT_SYMBOL(get_cycles);
static void nios2_timer_start(struct nios2_timer *timer)
{
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: drbg - use pragmas for disabling optimization
On 06/08/2015 07:08 PM, Stephan Mueller wrote: Hi, I performed measurements of the upper and lower boundary of the minimum and Shannon entropy for the RNG before the patch and after the patch. The values are very similar which demonstrates that the change does not affect the cryptographic characteristics of the RNG. The tests are available at: [1] shows the lower boundary of the fully non-optimized RNG [2] shows the lower boundary of the RNG with the patch below [3] shows the upper boundary of the fully non-optimized RNG [4] shows the upper boundary of the RNG with the patch below The pictures are fully explained in [5], but the key values are the minimum and Shannon entropy numbers in the legend of the graphs. [1] http://www.eperm.de/userspace-foldtime-testO0.data-single-time-dist-delta-3036-hist.pdf [2] http://www.eperm.de/userspace-foldtime-test-pragmas-O2.data-single-time-dist-delta-2370-hist.pdf [3] http://www.eperm.de/userspace-foldtime-testO0.data-varying-time-dist-delta-7302-hist.pdf [4] http://www.eperm.de/userspace-foldtime-test-pragmas-O2.data-varying-time-dist-delta-7055-hist.pdf [5] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf ---8<--- Replace the global -O0 compiler flag from the Makefile with GCC pragmas to mark only the functions required to be compiled without optimizations. This patch also adds a comment describing the rationale for the functions chosen to be compiled without optimizations. Signed-off-by: Stephan Mueller With openrisc, I get: CC [M] crypto/jitterentropy.o crypto/jitterentropy.c:266:9: warning: #pragma GCC target is not supported for this machine which may not be perfect, but is better than a compile error ;-). nios2 still fails to build with ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined! Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: drbg - use pragmas for disabling optimization
Hi Stephan, On Tue, 09 Jun 2015 04:08:49 +0200 Stephan Mueller wrote: > > Replace the global -O0 compiler flag from the Makefile with GCC > pragmas to mark only the functions required to be compiled without > optimizations. > > This patch also adds a comment describing the rationale for the > functions chosen to be compiled without optimizations. > > Signed-off-by: Stephan Mueller I will add this as a fix patch to the crypto tree merge today (unless someone yells at me). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpiEvcYpbwzr.pgp Description: OpenPGP digital signature
[PATCH] crypto: drbg - use pragmas for disabling optimization
Hi,
I performed measurements of the upper and lower boundary of the minimum and
Shannon entropy for the RNG before the patch and after the patch. The values
are very similar which demonstrates that the change does not affect the
cryptographic characteristics of the RNG.
The tests are available at:
[1] shows the lower boundary of the fully non-optimized RNG
[2] shows the lower boundary of the RNG with the patch below
[3] shows the upper boundary of the fully non-optimized RNG
[4] shows the upper boundary of the RNG with the patch below
The pictures are fully explained in [5], but the key values are the minimum
and Shannon entropy numbers in the legend of the graphs.
[1]
http://www.eperm.de/userspace-foldtime-testO0.data-single-time-dist-delta-3036-hist.pdf
[2]
http://www.eperm.de/userspace-foldtime-test-pragmas-O2.data-single-time-dist-delta-2370-hist.pdf
[3]
http://www.eperm.de/userspace-foldtime-testO0.data-varying-time-dist-delta-7302-hist.pdf
[4]
http://www.eperm.de/userspace-foldtime-test-pragmas-O2.data-varying-time-dist-delta-7055-hist.pdf
[5] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
---8<---
Replace the global -O0 compiler flag from the Makefile with GCC
pragmas to mark only the functions required to be compiled without
optimizations.
This patch also adds a comment describing the rationale for the
functions chosen to be compiled without optimizations.
Signed-off-by: Stephan Mueller
---
crypto/Makefile| 1 -
crypto/jitterentropy.c | 30 ++
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/crypto/Makefile b/crypto/Makefile
index 83b3c44..c842035 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -97,7 +97,6 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rng.o
obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o
obj-$(CONFIG_CRYPTO_DRBG) += drbg.o
-CFLAGS_jitterentropy.o = -O0
obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o
obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c
index 20dc178..9ba99e6 100644
--- a/crypto/jitterentropy.c
+++ b/crypto/jitterentropy.c
@@ -57,10 +57,6 @@
#include
#include
-#ifdef __OPTIMIZE__
- #error "The CPU Jitter random number generator must not be compiled with
optimizations. See documentation. Use the compiler switch -O0 for compiling
jitterentropy.c."
-#endif
-
/* The entropy pool */
struct rand_data {
/* all data values that are vital to maintain the security
@@ -188,6 +184,20 @@ static __u64 jent_loop_shuffle(struct rand_data *ec,
* Noise sources
***/
+/*
+ * The disabling of the optimizations is performed as documented and assessed
+ * thoroughly in http://www.chronox.de/jent.html. However, instead of disabling
+ * the optimization of the entire C file, only the main functions the jitter is
+ * measured for are not optimized. These functions include the noise sources as
+ * well as the main functions triggering the noise sources. As the time
+ * measurement is done from one invocation of the jitter noise source to the
+ * next, even the execution jitter of the code invoking the noise sources
+ * contribute to the overall randomness as well. The behavior of the RNG and
the
+ * statistical characteristics when only the mentioned functions are not
+ * optimized is almost equal to the a completely non-optimized RNG compilation
+ * as tested with the test tools provided at the initially mentioned web site.
+ */
+
/**
* CPU Jitter noise source -- this is the noise source based on the CPU
* execution time jitter
@@ -222,6 +232,8 @@ static __u64 jent_loop_shuffle(struct rand_data *ec,
*
* @return Number of loops the folding operation is performed
*/
+#pragma GCC push_options
+#pragma GCC optimize ("-O0")
static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
__u64 *folded, __u64 loop_cnt)
{
@@ -251,6 +263,7 @@ static __u64 jent_fold_time(struct rand_data *ec, __u64
time,
*folded = new;
return fold_loop_cnt;
}
+#pragma GCC pop_options
/**
* Memory Access noise source -- this is a noise source based on variations in
@@ -279,6 +292,8 @@ static __u64 jent_fold_time(struct rand_data *ec, __u64
time,
*
* @return Number of memory access operations
*/
+#pragma GCC push_options
+#pragma GCC optimize ("-O0")
static unsigned int jent_memaccess(struct rand_data *ec, __u64 loop_cnt)
{
unsigned char *tmpval = NULL;
@@ -318,6 +333,7 @@ static unsigned int jent_memaccess(struct rand_data *ec,
__u64 loop_cnt)
}
return i;
}
+#pragma GCC pop_options
/***
* Start of entropy processing logic
@@ -366,6 +382,8 @@ static void jent_stuck(struct rand_data *ec, __u64
current_delta)
*
* @return
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 16:51:24 schrieb Guenter Roeck: Hi Guenter, > >Yes, that fixes the problem (after I also removed the associated #error from >jitterentropy.c). Thank you for the confirmation. The patch will come tonight on this issue as I tested the cryptographic impact already. Thanks a lot for your help. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On 06/08/2015 04:33 PM, Stephan Mueller wrote: Am Monday 08 June 2015, 16:30:09 schrieb Guenter Roeck: Hi Guenter, get_cycles is implemented as static inline which executes mfspr(SPR_TTCR). SPR_TTCR is a constant. Normally that information seems to be passed on, but not when get_cycles() is compiled through jitterentropy. Any idea what might cause this ? Then it may be the optimization issue as well that Peter indicated. May I ask you for testing purposes (I do not have an OpenRISC) to remove the following line from crypto/Makefile: CFLAGS_jitterentropy.o = -O0 Yes, that fixes the problem (after I also removed the associated #error from jitterentropy.c). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 16:30:09 schrieb Guenter Roeck: Hi Guenter, > >get_cycles is implemented as static inline which executes mfspr(SPR_TTCR). >SPR_TTCR is a constant. Normally that information seems to be passed on, >but not when get_cycles() is compiled through jitterentropy. > >Any idea what might cause this ? Then it may be the optimization issue as well that Peter indicated. May I ask you for testing purposes (I do not have an OpenRISC) to remove the following line from crypto/Makefile: CFLAGS_jitterentropy.o = -O0 Note, that should just serve for testing. I will post a patch later that will replace the -O0 statement with a pragma. Thanks a lot. > >Thanks, >Guenter Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On 06/08/2015 03:36 PM, Stephan Mueller wrote:
Am Monday 08 June 2015, 12:54:12 schrieb Guenter Roeck:
Hi Guenter,
Thanks for the note.
...
---
openrisc:defconfig:
In file included from ./arch/openrisc/include/asm/timex.h:23:0,
...
from crypto/jitterentropy.c:52:
./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle':
./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably
doesn't match constraints
./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm'
I received this one also before. But that seems to be an error on the OpenRISC
platform as the random_get_entropy() function or the get_cycles function is
not implemented as defined.
The crypto code uses the following which triggers the issue:
__u64 tmp = 0;
tmp = random_get_entropy();
That one seems to be an appropriate use of random_get_entropy() which on
almost all arches is an alias for get_cycles().
Yes and no. I suspect it may have something to do with the compiler options.
The code compiles with the following patch applied.
---
diff --git a/arch/openrisc/include/asm/spr.h b/arch/openrisc/include/asm/spr.h
index 1cccb42dd477..373532cc41f4 100644
--- a/arch/openrisc/include/asm/spr.h
+++ b/arch/openrisc/include/asm/spr.h
@@ -24,7 +24,7 @@
"l.mtspr %0,%1,%2" \
: : "r" (_off), "r" (_val), "K" (_spr))
-static inline unsigned long mfspr(unsigned long add)
+static inline unsigned long mfspr(const unsigned long add)
{
unsigned long ret;
__asm__ __volatile__ ("l.mfspr %0,r0,%1" : "=r" (ret) : "K" (add));
---
get_cycles is implemented as static inline which executes mfspr(SPR_TTCR).
SPR_TTCR is a constant. Normally that information seems to be passed on,
but not when get_cycles() is compiled through jitterentropy.
Any idea what might cause this ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 12:54:12 schrieb Guenter Roeck: Hi Guenter, Thanks for the note. ... > >--- > >openrisc:defconfig: > >In file included from ./arch/openrisc/include/asm/timex.h:23:0, > ... > from crypto/jitterentropy.c:52: >./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle': >./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably >doesn't match constraints >./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm' I received this one also before. But that seems to be an error on the OpenRISC platform as the random_get_entropy() function or the get_cycles function is not implemented as defined. The crypto code uses the following which triggers the issue: __u64 tmp = 0; tmp = random_get_entropy(); That one seems to be an appropriate use of random_get_entropy() which on almost all arches is an alias for get_cycles(). > >--- > >nios2:3c120_defconfig: > >ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined! Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote: > On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote: > > Building with the attached random configuration file, > > Hit the very same error against next-20150605. > There are also several failing default configurations. Guenter --- um:defconfig: include/asm-generic/fixmap.h: In function 'fix_to_virt': include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative --- x86_64:defconfig: i386:defconfig: ./arch/x86/include/asm/qspinlock.h: In function 'native_queued_spin_unlock': ./arch/x86/include/asm/qspinlock.h:17:2: error: call to '__compiletime_assert_17' declared with attribute error: Need native word sized stores/loads for atomicity. --- openrisc:defconfig: In file included from ./arch/openrisc/include/asm/timex.h:23:0, ... from crypto/jitterentropy.c:52: ./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle': ./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably doesn't match constraints ./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm' --- nios2:3c120_defconfig: ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined! -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2 1/2] crypto: add PKE API
On Wed, May 6, 2015 at 12:36 PM, Tadeusz Struk wrote:
> Add Public Key Encryption API.
>
> Signed-off-by: Tadeusz Struk
> ---
> crypto/Kconfig |6 +
> crypto/Makefile|1
> crypto/crypto_user.c | 24 +++
> crypto/pkey.c | 125 ++
> include/crypto/pkey.h | 390
>
> include/linux/crypto.h |1
> include/linux/cryptouser.h |7 +
> 7 files changed, 554 insertions(+)
> create mode 100644 crypto/pkey.c
> create mode 100644 include/crypto/pkey.h
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 8aaf298..daa9c07 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -87,6 +87,12 @@ config CRYPTO_PCOMP2
> tristate
> select CRYPTO_ALGAPI2
>
> +config CRYPTO_PKEY
> + tristate "Public Key Algorithms API"
> + select CRYPTO_ALGAPI
> + help
> + Crypto API interface for public key algorithms.
> +
> config CRYPTO_MANAGER
> tristate "Cryptographic algorithm manager"
> select CRYPTO_MANAGER2
> diff --git a/crypto/Makefile b/crypto/Makefile
> index 97b7d3a..1930f85 100644
> --- a/crypto/Makefile
> +++ b/crypto/Makefile
> @@ -27,6 +27,7 @@ crypto_hash-y += shash.o
> obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
>
> obj-$(CONFIG_CRYPTO_PCOMP2) += pcompress.o
> +obj-$(CONFIG_CRYPTO_PKEY) += pkey.o
>
> cryptomgr-y := algboss.o testmgr.o
>
> diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
> index 41dfe76..ccc7f1d 100644
> --- a/crypto/crypto_user.c
> +++ b/crypto/crypto_user.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> #include "internal.h"
>
> @@ -110,6 +111,23 @@ nla_put_failure:
> return -EMSGSIZE;
> }
>
> +static int crypto_report_pkey(struct sk_buff *skb, struct crypto_alg *alg)
> +{
> + struct crypto_report_pkey rpkey;
> +
> + strncpy(rpkey.type, "pke", sizeof(rpkey.type));
> + strncpy(rpkey.subtype, alg->cra_name, sizeof(rpkey.subtype));
While subtype and cra_name are the same length, it may be possible to
pass an unterminated cra_name? Should this use strlcpy instead of
strncpy?
> + rpkey.capabilities = __crypto_pkey_alg(alg)->capabilities;
> +
> + if (nla_put(skb, CRYPTOCFGA_REPORT_PKEY,
> + sizeof(struct crypto_report_pkey), &rpkey))
> + goto nla_put_failure;
> + return 0;
> +
> +nla_put_failure:
> + return -EMSGSIZE;
> +}
> +
> static int crypto_report_one(struct crypto_alg *alg,
> struct crypto_user_alg *ualg, struct sk_buff
> *skb)
> {
> @@ -154,6 +172,12 @@ static int crypto_report_one(struct crypto_alg *alg,
> goto nla_put_failure;
>
> break;
> +
> + case CRYPTO_ALG_TYPE_PKEY:
> + if (crypto_report_pkey(skb, alg))
> + goto nla_put_failure;
> +
> + break;
> }
>
> out:
> diff --git a/crypto/pkey.c b/crypto/pkey.c
> new file mode 100644
> index 000..ab8c0e9
> --- /dev/null
> +++ b/crypto/pkey.c
> @@ -0,0 +1,125 @@
> +/*
> + * Public Key Encryption
> + *
> + * Copyright (c) 2015, Intel Corporation
> + * Authors: Tadeusz Struk
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "internal.h"
> +
> +#ifdef CONFIG_NET
> +static int crypto_pkey_report(struct sk_buff *skb, struct crypto_alg *alg)
> +{
> + struct crypto_report_pkey rep_pkey;
> +
> + strncpy(rep_pkey.type, "pkey", sizeof(rep_pkey.type));
> + strncpy(rep_pkey.subtype, alg->cra_name, sizeof(rep_pkey.subtype));
> + rep_pkey.capabilities = __crypto_pkey_alg(alg)->capabilities;
> +
> + if (nla_put(skb, CRYPTOCFGA_REPORT_PKEY,
> + sizeof(struct crypto_report_pkey), &rep_pkey))
> + goto nla_put_failure;
> + return 0;
> +
> +nla_put_failure:
> + return -EMSGSIZE;
> +}
> +#else
> +static int crypto_pkey_report(struct sk_buff *skb, struct crypto_alg *alg)
> +{
> + return -ENOSYS;
> +}
> +#endif
This is identical to crypto_user's crypto_pkey_report. Perhaps extract it?
> +
> +static void crypto_pkey_show(struct seq_file *m, struct crypto_alg *alg)
> + __attribute__ ((unused));
> +static void crypto_pkey_show(struct seq_file *m, struct crypto_alg *alg)
> +{
> + int cap = __crypto_pkey_alg(alg)->capabilities;
> +
> + seq_puts(m, "type : pke\n");
> + seq_printf(m, "subtype : %s\n", alg->cra_name);
> + seq_printf(m, "can encrypt : %s\n",
> + cap & PKEY_CAN_ENCRYPT ? "yes" : "no");
> + se
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On Mon, 2015-06-08 at 17:52 +0200, Stephan Mueller wrote:
> Am Monday 08 June 2015, 14:36:30 schrieb Peter Zijlstra:
>
> Hi Peter,
> >
> >Would something like
> >
> >#pragma GCC push_options
> >#pragma GCC optimize ("-O0")
> >static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> > __u64 *folded, __u64 loop_cnt)
> >{
> > ...
> >}
> >#pragma GCC pop_options
> >
> >Be an option to allow the file to be compiled with regular optimizations
> >enabled?
>
> After doing some tests, I see that neither the min entropy nor the Shannon
> Entropy of the raw noise is affected by using the mentioned pragmas at the
> right locations.
>
> So I will prepare a patch tonight.
>
> Just for my edification: why does an -O0 on a self contained file break the
> compile run?
We rely on -finline-functions, which is disabled with -O0.
By inlining some things, the compiler can do constant value propagation
etc. and compile time evaluate things.
We often (as is the case here) use this to generate compiler warns
without generating actual code.
> Any why do the pragmas work?
They are placed such that the code affected by the above creativity is
outside of the forced -O0 compile and life is good again.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 14:36:30 schrieb Peter Zijlstra:
Hi Peter,
>
>Would something like
>
>#pragma GCC push_options
>#pragma GCC optimize ("-O0")
>static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> __u64 *folded, __u64 loop_cnt)
>{
> ...
>}
>#pragma GCC pop_options
>
>Be an option to allow the file to be compiled with regular optimizations
>enabled?
After doing some tests, I see that neither the min entropy nor the Shannon
Entropy of the raw noise is affected by using the mentioned pragmas at the
right locations.
So I will prepare a patch tonight.
Just for my edification: why does an -O0 on a self contained file break the
compile run? Any why do the pragmas work?
Thanks
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crypto: caam - Clamp AEAD SG list by input length
On 06/08/2015 06:53 AM, Herbert Xu wrote:
> On Mon, Jun 08, 2015 at 06:46:14AM -0700, Tadeusz Struk wrote:
>> On 06/08/2015 01:38 AM, Herbert Xu wrote:
>>> +static inline struct sec4_sg_entry *sg_to_sec4_sg_len(
>>> + struct scatterlist *sg, unsigned int total,
>>> + struct sec4_sg_entry *sec4_sg_ptr)
>>> +{
>>> + do {
>>> + unsigned int len = min(sg_dma_len(sg), total);
>>> +
>>> + dma_to_sec4_sg_one(sec4_sg_ptr, sg_dma_address(sg), len, 0);
>>> + sec4_sg_ptr++;
>>> + sg = sg_next(sg);
>>> + total -= len;
>>> + } while (total);
>>> + return sec4_sg_ptr - 1;
>>> +}
>>
>> Is req->assoclen guaranteed to be assoc->length aligned?
>
> No req->assoclen can be any length. What is the problem?
There is no problem, just asking.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crypto: caam - Clamp AEAD SG list by input length
On Mon, Jun 08, 2015 at 06:46:14AM -0700, Tadeusz Struk wrote:
> On 06/08/2015 01:38 AM, Herbert Xu wrote:
> > +static inline struct sec4_sg_entry *sg_to_sec4_sg_len(
> > + struct scatterlist *sg, unsigned int total,
> > + struct sec4_sg_entry *sec4_sg_ptr)
> > +{
> > + do {
> > + unsigned int len = min(sg_dma_len(sg), total);
> > +
> > + dma_to_sec4_sg_one(sec4_sg_ptr, sg_dma_address(sg), len, 0);
> > + sec4_sg_ptr++;
> > + sg = sg_next(sg);
> > + total -= len;
> > + } while (total);
> > + return sec4_sg_ptr - 1;
> > +}
>
> Is req->assoclen guaranteed to be assoc->length aligned?
No req->assoclen can be any length. What is the problem?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crypto: caam - Clamp AEAD SG list by input length
On 06/08/2015 01:38 AM, Herbert Xu wrote:
> +static inline struct sec4_sg_entry *sg_to_sec4_sg_len(
> + struct scatterlist *sg, unsigned int total,
> + struct sec4_sg_entry *sec4_sg_ptr)
> +{
> + do {
> + unsigned int len = min(sg_dma_len(sg), total);
> +
> + dma_to_sec4_sg_one(sec4_sg_ptr, sg_dma_address(sg), len, 0);
> + sec4_sg_ptr++;
> + sg = sg_next(sg);
> + total -= len;
> + } while (total);
> + return sec4_sg_ptr - 1;
> +}
Is req->assoclen guaranteed to be assoc->length aligned?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Montag, 8. Juni 2015, 14:36:30 schrieb Peter Zijlstra:
Hi Peter,
> Adding Stephan to Cc.
>
> On Mon, 2015-06-08 at 20:25 +0800, Herbert Xu wrote:
> > On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote:
> > > > Building with the attached random configuration file,
> > >
> > > Hit the very same error against next-20150605.
> > >
> > > The issue with that file we have no compiler optimization enabled. So,
> > > guys, how you would recommend to fix it?
> >
> > Stephan, can we get rid of the no optimisation requirement?
>
> Would something like
>
> #pragma GCC push_options
> #pragma GCC optimize ("-O0")
> static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> __u64 *folded, __u64 loop_cnt)
> {
> ...
> }
> #pragma GCC pop_options
>
> Be an option to allow the file to be compiled with regular optimizations
> enabled?
Yes, that is also possible. I was not aware of the fact that the optimization
is the problem. I got another report fom Fengguang Wu about a compile issue on
AVR32 which I found out relates to the same issue.
I will prepare a patch shortly.
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] crypto: drbg - initialize in subsys_initcall
When compiling the DRBG statically into the kernel, the testmgr
allocation of the DRBG may be done at a time the Jitter RNG is
not available as it is registered later. The patch changes the
initialization to be invoked in subsys_initcall.
Signed-off-by: Stephan Mueller
---
crypto/jitterentropy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c
index a60147e..20dc178 100644
--- a/crypto/jitterentropy.c
+++ b/crypto/jitterentropy.c
@@ -897,7 +897,7 @@ static void __exit jent_mod_exit(void)
crypto_unregister_rng(&jent_alg);
}
-module_init(jent_mod_init);
+subsys_initcall(jent_mod_init);
module_exit(jent_mod_exit);
MODULE_LICENSE("Dual BSD/GPL");
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Adding Stephan to Cc.
On Mon, 2015-06-08 at 20:25 +0800, Herbert Xu wrote:
> On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> > On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote:
> > > Building with the attached random configuration file,
> >
> > Hit the very same error against next-20150605.
> >
> > The issue with that file we have no compiler optimization enabled. So,
> > guys, how you would recommend to fix it?
>
> Stephan, can we get rid of the no optimisation requirement?
Would something like
#pragma GCC push_options
#pragma GCC optimize ("-O0")
static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
__u64 *folded, __u64 loop_cnt)
{
...
}
#pragma GCC pop_options
Be an option to allow the file to be compiled with regular optimizations
enabled?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote: > On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote: > > Building with the attached random configuration file, > > Hit the very same error against next-20150605. > > The issue with that file we have no compiler optimization enabled. So, > guys, how you would recommend to fix it? Stephan, can we get rid of the no optimisation requirement? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote: > Building with the attached random configuration file, Hit the very same error against next-20150605. The issue with that file we have no compiler optimization enabled. So, guys, how you would recommend to fix it? By the way, I'm building the x86_64_defconfig with following changes diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 315b861..363824f 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -172,9 +172,11 @@ CONFIG_TIGON3=y CONFIG_NET_TULIP=y CONFIG_E100=y CONFIG_E1000=y +CONFIG_E1000E=y CONFIG_SKY2=y CONFIG_FORCEDETH=y CONFIG_8139TOO=y +CONFIG_R8169=y CONFIG_FDDI=y CONFIG_INPUT_POLLDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set @@ -198,7 +200,7 @@ CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_INTEL is not set # CONFIG_HW_RANDOM_AMD is not set CONFIG_NVRAM=y -CONFIG_HPET=y +# CONFIG_HPET is not set # CONFIG_HPET_MMAP is not set CONFIG_I2C_I801=y CONFIG_WATCHDOG=y @@ -206,8 +208,8 @@ CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y CONFIG_DRM=y -CONFIG_DRM_I915=y -CONFIG_DRM_I915_KMS=y +# CONFIG_DRM_I915 is not set +CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_EFI=y @@ -224,8 +226,8 @@ CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_HRTIMER=y -CONFIG_SND_HDA_INTEL=y -CONFIG_SND_HDA_HWDEP=y +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDA_HWDEP is not set CONFIG_HIDRAW=y CONFIG_HID_GYRATION=y CONFIG_LOGITECH_FF=y @@ -307,3 +309,56 @@ CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DISABLE=y # CONFIG_CRYPTO_ANSI_CPRNG is not set +CONFIG_FUNCTION_TRACER=y +CONFIG_I2C_DESIGNWARE_PCI=y +CONFIG_I2C_DESIGNWARE_PLATFORM=m +CONFIG_GPIOLIB=y +CONFIG_GPIO_INTEL_MID=y +CONFIG_INTEL_MID_WATCHDOG=y +CONFIG_NOP_USB_XCEIV=y +CONFIG_USB_CHIPIDEA=y +CONFIG_USB_CHIPIDEA_UDC=y +CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_X86_EXTENDED_PLATFORM=y +CONFIG_X86_INTEL_MID=y +CONFIG_EFI_STUB=y +CONFIG_EFI_MIXED=y +CONFIG_EARLY_PRINTK_EFI=y +CONFIG_FB=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_DYNAMIC_DEBUG=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_SERIAL=y +CONFIG_USB_SERIAL_PL2303=y +CONFIG_USB_USBNET=y +CONFIG_USB_NET_AX88179_178A=y +CONFIG_USB_NET_MCS7830=y +CONFIG_USB_NET_AX8817X=y +CONFIG_X86_INTEL_LPSS=y +CONFIG_PM_RUNTIME=y +CONFIG_DW_DMAC_CORE=m +CONFIG_DW_DMAC=m +CONFIG_DW_DMAC_PCI=m +CONFIG_DMATEST=m +CONFIG_SERIAL_8250_DMA=y +CONFIG_SERIAL_8250_PCI=y +CONFIG_SERIAL_8250_DW=m +CONFIG_MMC=m +CONFIG_MMC_SDHCI=m +CONFIG_MMC_SDHCI_ACPI=m +CONFIG_ACPI_DEBUG=y +CONFIG_ACPI_PROCFS_POWER=y +CONFIG_DMA_API_DEBUG=y +CONFIG_DEBUG_LOCKDEP=y +CONFIG_DEBUG_SHIRQ=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_BAYTRAIL=y +CONFIG_PWM=y +CONFIG_PWM_LPSS=m +CONFIG_PWM_LPSS_PCI=m +CONFIG_PWM_LPSS_PLATFORM=m +CONFIG_SPI=y +CONFIG_SPI_PXA2XX_PCI=m +CONFIG_SPI_PXA2XX=m > > In file included from ./arch/x86/include/asm/spinlock.h:46:0, > from include/linux/spinlock.h:87, > from include/linux/seqlock.h:35, > from include/linux/time.h:5, > from include/linux/stat.h:18, > from include/linux/module.h:10, > from crypto/jitterentropy.c:52: > In function ‘native_queued_spin_unlock’, > inlined from ‘queued_spin_unlock’ at > ./arch/x86/include/asm/qspinlock.h:38:2 > , > inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2, > inlined from ‘__raw_spin_unlock’ at > include/linux/spinlock_api_smp.h:153:2, > inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2, > inlined from ‘jent_kcapi_cleanup’ at crypto/jitterentropy.c:844:2: > ./arch/x86/include/asm/qspinlock.h:17:317: error: call to > ‘__compiletime_assert_17’ declared with attribute error: Need native > word sized stores/loads for atomicity. > In function ‘native_queued_spin_unlock’, > inlined from ‘queued_spin_unlock’ at > ./arch/x86/include/asm/qspinlock.h:38:2 > , > inlined from ‘do_raw_spin_unlock’ at include/linux/spinlock.h:175:2, > inlined from ‘__raw_spin_unlock’ at > include/linux/spinlock_api_smp.h:153:2, > inlined from ‘spin_unlock’ at include/linux/spinlock.h:357:2, > inlined from ‘jent_kcapi_random’ at crypto/jitterentropy.c:856:2: > ./arch/x86/include/asm/qspinlock.h:17:317: error: call to > ‘__compiletime_assert_17’ declared with attribute error: Need native > word sized stores/loads for atomicity. > scripts/Makefile.build:264: recipe for target 'crypto/jitterentropy.o' failed -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: drbg - decrease verbosity
Am Montag, 8. Juni 2015, 09:33:55 schrieb Herbert Xu: Hi Herbert, > On Sat, Jun 06, 2015 at 04:20:35AM +0200, Stephan Mueller wrote: > > When compiling the DRBG statically into the kernel, the testmgr > > allocation of the DRBG may be done at a time the Jitter RNG is > > not available. The testmgr instantiates a number of DRBGs for performing > > testing which may cause a flurry of logs about unavailable Jitter RNG. > > Note, the Jitter RNG is not needed for the testmgr operation anyways. > > I think we should fix by ensuring the jitter is registered first. > You could try registering jitter at subsys_init instead of module_init. Thanks for the hint about the root cause. I will do that right away. > > Cheers, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crypto driver -DCP
On Monday, June 08, 2015 at 06:52:00 AM, Herbert Xu wrote: > On Fri, Jun 05, 2015 at 04:38:03PM +0200, Marek Vasut wrote: > > In general, it would probably make sense to add a flag to .setkey() to > > store the key in a keyslot. The keyslot allocation would be up to the > > driver. In case all keyslots would be full, the setkey() with the flag > > set would simply fail. This would imply you would need to have a > > counterpart function to .setkey() to free keyslots -- something like > > .unsetkey() . > > Changing setkey is going to cause too much churn. In any case > I don't think these key slots should be written to by the kernel > since the intention appears to be for entites outside the kernel > to place secret keys in there that can then be used but not read > by the kernel. You mean like bootloader or you mean userspace code ? Maybe Jay can explain how these slots are intended to be used. I'd like to know the expected usecase. > So as far as the kernel is concerned these are constant keys. > > Therefore there should be no need for unsetkey. > > So perhaps just add a new call setkey_slot that is optional and > only needs to be implemented by drivers such as ccp. Might work as well ... but let's maybe wait for the usecase. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
crypto: caam - Clamp AEAD SG list by input length
Currently caam assumes that the SG list contains exactly the number
of bytes required. This assumption is incorrect.
Up until now this has been harmless. However with the new AEAD
interface this now breaks as the AD SG list contains more bytes
than just the AD.
This patch fixes this by always clamping the AD SG list by the
specified AD length.
Signed-off-by: Herbert Xu
---
drivers/crypto/caam/caamalg.c| 20
drivers/crypto/caam/sg_sw_sec4.h | 15 +++
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 3d850ab..3c37fe6 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -2713,10 +2713,8 @@ static struct aead_edesc *aead_edesc_alloc(struct
aead_request *req,
sec4_sg_index = 0;
if (!all_contig) {
if (!is_gcm) {
- sg_to_sec4_sg(req->assoc,
- assoc_nents,
- edesc->sec4_sg +
- sec4_sg_index, 0);
+ sg_to_sec4_sg_len(req->assoc, req->assoclen,
+ edesc->sec4_sg + sec4_sg_index);
sec4_sg_index += assoc_nents;
}
@@ -2725,10 +2723,8 @@ static struct aead_edesc *aead_edesc_alloc(struct
aead_request *req,
sec4_sg_index += 1;
if (is_gcm) {
- sg_to_sec4_sg(req->assoc,
- assoc_nents,
- edesc->sec4_sg +
- sec4_sg_index, 0);
+ sg_to_sec4_sg_len(req->assoc, req->assoclen,
+ edesc->sec4_sg + sec4_sg_index);
sec4_sg_index += assoc_nents;
}
@@ -2953,8 +2949,8 @@ static struct aead_edesc *aead_giv_edesc_alloc(struct
aead_givcrypt_request
sec4_sg_index = 0;
if (!(contig & GIV_SRC_CONTIG)) {
if (!is_gcm) {
- sg_to_sec4_sg(req->assoc, assoc_nents,
- edesc->sec4_sg + sec4_sg_index, 0);
+ sg_to_sec4_sg_len(req->assoc, req->assoclen,
+ edesc->sec4_sg + sec4_sg_index);
sec4_sg_index += assoc_nents;
}
@@ -2963,8 +2959,8 @@ static struct aead_edesc *aead_giv_edesc_alloc(struct
aead_givcrypt_request
sec4_sg_index += 1;
if (is_gcm) {
- sg_to_sec4_sg(req->assoc, assoc_nents,
- edesc->sec4_sg + sec4_sg_index, 0);
+ sg_to_sec4_sg_len(req->assoc, req->assoclen,
+ edesc->sec4_sg + sec4_sg_index);
sec4_sg_index += assoc_nents;
}
diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index 3b91821..efbc1db 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -55,6 +55,21 @@ static inline void sg_to_sec4_sg_last(struct scatterlist
*sg, int sg_count,
sec4_sg_ptr->len |= SEC4_SG_LEN_FIN;
}
+static inline struct sec4_sg_entry *sg_to_sec4_sg_len(
+ struct scatterlist *sg, unsigned int total,
+ struct sec4_sg_entry *sec4_sg_ptr)
+{
+ do {
+ unsigned int len = min(sg_dma_len(sg), total);
+
+ dma_to_sec4_sg_one(sec4_sg_ptr, sg_dma_address(sg), len, 0);
+ sec4_sg_ptr++;
+ sg = sg_next(sg);
+ total -= len;
+ } while (total);
+ return sec4_sg_ptr - 1;
+}
+
/* count number of elements in scatterlist */
static inline int __sg_count(struct scatterlist *sg_list, int nbytes,
bool *chained)
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
