date:20160222

Re: 3.14.61 breaks dm disk drive encryption?

2016-02-22 Thread Stephan Mueller

Am Montag, 22. Februar 2016, 22:17:55 schrieb J. Paul Reed:

Hi J,

> Hey all,
> 
> I just upgraded from 3.14.60 to 3.14.61, and when I try to mount my
> luks-encrypted disk drives, I get an error saying the mapping couldn't be
> created and to check whether aes-xts-plain64 is compiled into the kernel;
> it is:
> 
> [preed@underworld linux-3.14.61]$ grep CRYPTO_AES .config
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_X86_64=y
> CONFIG_CRYPTO_AES_NI_INTEL=y
> 
> This all works fine with 3.14.60 (and previous 3.14-versions), and I
> compiled .61 by copying the .config over and "make oldconfig"'ing, so I'd
> expect this to work.
> 
> I looked around for other config options I need to turn on but nothing
> popped out at me. Looking through the changelog for 3.14.61, perhaps this
> is related to the fix for 7e6978fb73 ?
> 
> I can provide more exact error messaging if it'd help, but I'd expect a
> "make oldconfig" to carry over all the options correctly, as it's done for
> the rest of the 3.14 kernels.

Please see the thread "Broken userspace in crypto in linux-4.1.8" from last 
week in this mailing list for details.
> 
> Any ideas?
> 
> thanks,
> preed


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

3.14.61 breaks dm disk drive encryption?

2016-02-22 Thread J. Paul Reed


Hey all,

I just upgraded from 3.14.60 to 3.14.61, and when I try to mount my
luks-encrypted disk drives, I get an error saying the mapping couldn't be
created and to check whether aes-xts-plain64 is compiled into the kernel;
it is:

[preed@underworld linux-3.14.61]$ grep CRYPTO_AES .config
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=y

This all works fine with 3.14.60 (and previous 3.14-versions), and I
compiled .61 by copying the .config over and "make oldconfig"'ing, so I'd
expect this to work.

I looked around for other config options I need to turn on but nothing
popped out at me. Looking through the changelog for 3.14.61, perhaps this
is related to the fix for 7e6978fb73 ?

I can provide more exact error messaging if it'd help, but I'd expect a
"make oldconfig" to carry over all the options correctly, as it's done for
the rest of the 3.14 kernels.

Any ideas?

thanks,
preed
-- 
J. Paul Reed
Release Engineering Approaches
Simply ship. Every time.

http://release-approaches.com/
(415) 226-9655

--
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 4/8] akcipher: Move the RSA DER encoding to the crypto layer

2016-02-22 Thread Andrew Zaborowski

Hi,

On 22 February 2016 at 23:28, David Howells  wrote:
> Tadeusz Struk  wrote:
>
>> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
>> that we already have. Looks like the two do the same padding now.

I think that'd be a good thing to do.

>> Should we merge then and pass the hash param as a separate template param,
>> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"?
>
> Ummm...  Possibly.  Is that how it's used?

Currently it only does the padding and doesn't care about the hash.
The input is expected to be the entire DigestInfo struct.

AIUI Tadeusz is proposing adding the hashing as a new feature.  Note
though that the hash paremeter won't make sense for the encrypt,
decrypt or verify operations.

Also note that TLS 1.0 uses the padding to sign data that is not a
DigestInfo structure and even for 1.2 there are situations where
you'll be hashing the data yourself over some time and then you'll
want the algorithm to only do the padding and RSA signing.

Cheers
--
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 4/8] akcipher: Move the RSA DER encoding to the crypto layer

2016-02-22 Thread Tadeusz Struk

On 02/22/2016 02:28 PM, David Howells wrote:
> Tadeusz Struk  wrote:
> 
>> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
>> that we already have. Looks like the two do the same padding now.
>> Should we merge then and pass the hash param as a separate template param,
>> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"?
> 
> Ummm...  Possibly.  Is that how it's used?
> 
>   warthog>git grep pkcs1pad -- Documentation
>   warthog1>

Yes, no docs. Sorry.

> 
> Anyway, the problem I have with this is that I want to get that knowledge out
> of the asymmetric key in-software public key subtype.  It knows "rsa", "dsa",
> "ecdsa", ... because that's all the OIDs tell it.

Rigth, for now the public_key would need to build the full algorithm string as
follows:

vsprintf(name, "pkcs1pad(%s, %s)", pkey_algo_name[sig->pkey_algo],
 hash_algo_name[sig->pkey_hash_algo]);

Do you plan to add more padding schemes later? 

> 
> I guess if I have to, I can stoop to converting "rsa" to "pkcs1pad(rsa, 
> sha1)".
> 
> Can you do me a really quick merge?  -rc5 is already out, and I want to get it
> to James pronto - plus I have things that are pending on this change being
> made.

Yes, I can start woring on a subsequent patch based on your changes in
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
Is that ok with you?

> 
> Oh - and how does the padding template find the algorithm DER encoding string
> to use?  I have wondered whether it should be stored in with the hash
> algorithm, but it probably makes more sense to keep it with the rsa module.

We can put everything into the crypto/rsa-pkcs1pad.c
This is where all the padding logic should be, I think.
Thanks,
-- 
TS
--
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 4/8] akcipher: Move the RSA DER encoding to the crypto layer

2016-02-22 Thread David Howells

Tadeusz Struk  wrote:

> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template
> that we already have. Looks like the two do the same padding now.
> Should we merge then and pass the hash param as a separate template param,
> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"?

Ummm...  Possibly.  Is that how it's used?

warthog>git grep pkcs1pad -- Documentation
warthog1>

Anyway, the problem I have with this is that I want to get that knowledge out
of the asymmetric key in-software public key subtype.  It knows "rsa", "dsa",
"ecdsa", ... because that's all the OIDs tell it.

I guess if I have to, I can stoop to converting "rsa" to "pkcs1pad(rsa, sha1)".

Can you do me a really quick merge?  -rc5 is already out, and I want to get it
to James pronto - plus I have things that are pending on this change being
made.

Oh - and how does the padding template find the algorithm DER encoding string
to use?  I have wondered whether it should be stored in with the hash
algorithm, but it probably makes more sense to keep it with the rsa module.

David
--
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 0/8] X.509: Software public key subtype changes

2016-02-22 Thread Tadeusz Struk

On 02/19/2016 09:18 AM, David Howells wrote:
> 
> Here's a set of patches that cleans up the public key handling in the
> asymmetric key functions:
> 
>  (1) - (3) These are Tadeusz's RSA akcipher conversion.

Thanks for taking this David.

> 
>  (4) This removes all knowledge of RSA from the software public key
>  asymmetric key subtype.  Instead, the public key type and the hash
>  type are indicated to the crypto layer and the RSA module there does
>  all the appropriate encoding.
> 
>  (5) This changes the various algorithm IDs to text labels instead of enums
>  as the strings are what we actually deal with (printing, passing to
>  the crypto layer).
> 
>  (6) This separates the private parts of the software public key subtype
>  into a private header in the implementation directory.
> 
>  (7) This renames public_key.c to software_pkey.c and changes the Kconfig
>  symbol to match.
> 
>  (8) This renames symbols beginning "public_key" to "software_pkey" except
>  struct for public_key_signature which is a wider API component.
> 
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa
> 
> David
> ---
> David Howells (5):
>   akcipher: Move the RSA DER encoding to the crypto layer
>   X.509: Make algo identifiers text instead of enum
>   X.509: Make the public_key asymmetric key type internal data private
>   X.509: Rename public_key.c to software_pkey.c
>   X.509: Rename public_key* to software_pkey*
> 
> Tadeusz Struk (3):
>   crypto: KEYS: convert public key and digsig asym to the akcipher api
>   integrity: convert digsig to akcipher api
>   crypto: public_key: remove MPIs from public_key_signature struct
> 
> 
>  arch/s390/configs/default_defconfig   |2 
>  arch/s390/configs/gcov_defconfig  |2 
>  arch/s390/configs/performance_defconfig   |2 
>  crypto/asymmetric_keys/Kconfig|   17 +-
>  crypto/asymmetric_keys/Makefile   |   10 -
>  crypto/asymmetric_keys/mscode_parser.c|   14 +
>  crypto/asymmetric_keys/pkcs7_parser.c |   30 +--
>  crypto/asymmetric_keys/pkcs7_trust.c  |2 
>  crypto/asymmetric_keys/pkcs7_verify.c |   12 +
>  crypto/asymmetric_keys/public_key.c   |  130 --
>  crypto/asymmetric_keys/public_key.h   |   36 
>  crypto/asymmetric_keys/rsa.c  |  278 
> -
>  crypto/asymmetric_keys/software_pkey.c|  142 +++
>  crypto/asymmetric_keys/software_pkey.h|   33 +++
>  crypto/asymmetric_keys/verify_pefile.c|4 
>  crypto/asymmetric_keys/verify_pefile.h|2 
>  crypto/asymmetric_keys/x509_cert_parser.c |   67 ++-
>  crypto/asymmetric_keys/x509_parser.h  |4 
>  crypto/asymmetric_keys/x509_public_key.c  |   43 ++--
>  crypto/asymmetric_keys/x509_rsakey.asn1   |4 
>  crypto/rsa.c  |  210 +++---
>  crypto/testmgr.c  |5 -
>  include/crypto/akcipher.h |7 +
>  include/crypto/public_key.h   |   79 +---
>  init/Kconfig  |4 
>  kernel/module_signing.c   |6 +
>  security/integrity/Kconfig|3 
>  security/integrity/digsig_asymmetric.c|   16 +-
>  28 files changed, 467 insertions(+), 697 deletions(-)
>  delete mode 100644 crypto/asymmetric_keys/public_key.c
>  delete mode 100644 crypto/asymmetric_keys/public_key.h
>  delete mode 100644 crypto/asymmetric_keys/rsa.c
>  create mode 100644 crypto/asymmetric_keys/software_pkey.c
>  create mode 100644 crypto/asymmetric_keys/software_pkey.h
>  delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
> 

-- 
TS
--
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 3/3] crypto: caam - add support for RSA algorithm

2016-02-22 Thread Tudor-Dan Ambarus

Hi Stephan,

> -Original Message-
> >+++ b/drivers/crypto/caam/caam_rsaprivkey.asn1
> >@@ -0,0 +1,11 @@
> >+RsaPrivKey ::= SEQUENCE {
> >+version INTEGER,
> >+n   INTEGER ({ caam_rsa_get_n }),
> >+e   INTEGER ({ caam_rsa_get_e }),
> >+d   INTEGER ({ caam_rsa_get_d }),
> >+prime1  INTEGER,
> >+prime2  INTEGER,
> >+exponent1   INTEGER,
> >+exponent2   INTEGER,
> >+coefficient INTEGER
> >+}
> 
> Why do you define your own ASN.1 sequence? Why not using the common
> crypto/rsaprivkey.asn1?
> 

[ta] The functions indicated in crypto/rsaprivkey.asn1 return the key members 
in MPI format. Our hardware expects the keys as u8 buffers; retrieving the key 
members in MPI format and then writing them to u8 buffers would be an 
unnecessary step.

> >diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
> >new file mode 100644
> >index 000..8dd5ff2
> >--- /dev/null
> >+++ b/drivers/crypto/caam/caampkc.c
> >@@ -0,0 +1,616 @@
> >+int caam_rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> >+   const void *value, size_t vlen)
> 
> This function and the following functions are very similar to the ones in
> rsa_helper.c -- shouldn't those be used instead?
> 

[ta] Those functions use the MPI lib and I don't need it.

> >+static void rsa_free_key(struct caam_pkc_context *ctx)
> >+{
> >+kfree(ctx->n);
> >+ctx->n = NULL;
> >+kfree(ctx->e);
> >+ctx->e = NULL;
> >+
> >+if (ctx->d) {
> >+memset(ctx->d, '\0', ctx->key_sz);
> >+kfree(ctx->d);
> 
> kzfree, please
> 

Thanks,
ta


--
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 3/3] crypto: caam - add support for RSA algorithm

2016-02-22 Thread Stephan Mueller

Am Montag, 22. Februar 2016, 11:16:17 schrieb Tudor Ambarus:

Hi Tudor,

>Add RSA support to caam driver.
>
>Coauthored-by: Yashpal Dutta 
>
>Signed-off-by: Tudor Ambarus 
>---
> drivers/crypto/caam/Kconfig  |  13 +
> drivers/crypto/caam/Makefile |  13 +
> drivers/crypto/caam/caam_rsaprivkey.asn1 |  11 +
> drivers/crypto/caam/caam_rsapubkey.asn1  |   4 +
> drivers/crypto/caam/caampkc.c| 616
>+++ drivers/crypto/caam/caampkc.h|
>106 ++
> drivers/crypto/caam/desc.h   |   2 +
> drivers/crypto/caam/pdb.h|  16 +-
> drivers/crypto/caam/pkc_desc.c   | 136 +++
> 9 files changed, 916 insertions(+), 1 deletion(-)
> create mode 100644 drivers/crypto/caam/caam_rsaprivkey.asn1
> create mode 100644 drivers/crypto/caam/caam_rsapubkey.asn1
> create mode 100644 drivers/crypto/caam/caampkc.c
> create mode 100644 drivers/crypto/caam/caampkc.h
> create mode 100644 drivers/crypto/caam/pkc_desc.c
>
>diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
>index 5652a53..5c1578f 100644
>--- a/drivers/crypto/caam/Kconfig
>+++ b/drivers/crypto/caam/Kconfig
>@@ -99,6 +99,19 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
> To compile this as a module, choose M here: the module
> will be called caamhash.
>
>+config CRYPTO_DEV_FSL_CAAM_PKC_API
>+tristate "Register public key cryptography implementations with
>Crypto API" +depends on CRYPTO_DEV_FSL_CAAM &&
>CRYPTO_DEV_FSL_CAAM_JR
>+default y
>+select CRYPTO_AKCIPHER
>+select ASN1
>+help
>+  Selecting this will allow SEC Public key support for RSA.
>+  Supported cryptographic primitives: encryption, decryption,
>+  signature and verification.
>+  To compile this as a module, choose M here: the module
>+  will be called caam_pkc.
>+
> config CRYPTO_DEV_FSL_CAAM_RNG_API
>   tristate "Register caam device for hwrng API"
>   depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
>diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
>index 550758a..d4a684c 100644
>--- a/drivers/crypto/caam/Makefile
>+++ b/drivers/crypto/caam/Makefile
>@@ -5,11 +5,24 @@ ifeq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG), y)
>   EXTRA_CFLAGS := -DDEBUG
> endif
>
>+$(obj)/caam_rsapubkey-asn1.o: $(obj)/caam_rsapubkey-asn1.c \
>+$(obj)/caam_rsapubkey-asn1.h
>+$(obj)/caam_rsaprivkey-asn1.o: $(obj)/caam_rsaprivkey-asn1.c \
>+ $(obj)/caam_rsaprivkey-asn1.h
>+
>+clean-files += caam_rsapubkey-asn1.c caam_rsapubkey-asn1.h
>+clean-files += caam_rsaprivkey-asn1.c caam_rsapvivkey-asn1.h
>+
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
> obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
>+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
>
> caam-objs := ctrl.o
> caam_jr-objs := jr.o key_gen.o error.o
>+caam_pkc-objs := caam_rsapubkey-asn1.o \
>+  caam_rsaprivkey-asn1.o \
>+  caampkc.o \
>+  pkc_desc.o
>diff --git a/drivers/crypto/caam/caam_rsaprivkey.asn1
>b/drivers/crypto/caam/caam_rsaprivkey.asn1 new file mode 100644
>index 000..c3a01e2
>--- /dev/null
>+++ b/drivers/crypto/caam/caam_rsaprivkey.asn1
>@@ -0,0 +1,11 @@
>+RsaPrivKey ::= SEQUENCE {
>+  version INTEGER,
>+  n   INTEGER ({ caam_rsa_get_n }),
>+  e   INTEGER ({ caam_rsa_get_e }),
>+  d   INTEGER ({ caam_rsa_get_d }),
>+  prime1  INTEGER,
>+  prime2  INTEGER,
>+  exponent1   INTEGER,
>+  exponent2   INTEGER,
>+  coefficient INTEGER
>+}

Why do you define your own ASN.1 sequence? Why not using the common 
crypto/rsaprivkey.asn1?

>diff --git a/drivers/crypto/caam/caam_rsapubkey.asn1
>b/drivers/crypto/caam/caam_rsapubkey.asn1 new file mode 100644
>index 000..d4bd741
>--- /dev/null
>+++ b/drivers/crypto/caam/caam_rsapubkey.asn1
>@@ -0,0 +1,4 @@
>+RsaPubKey ::= SEQUENCE {
>+  n INTEGER ({ caam_rsa_get_n }),
>+  e INTEGER ({ caam_rsa_get_e })
>+}
>diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
>new file mode 100644
>index 000..8dd5ff2
>--- /dev/null
>+++ b/drivers/crypto/caam/caampkc.c
>@@ -0,0 +1,616 @@
>+/*
>+ * caam - Freescale FSL CAAM support for Public Key Cryptography
>+ *
>+ * Copyright 2016 Freescale Semiconductor, Inc.
>+ *
>+ * There is no Shared Descriptor for PKC so that the Job Descriptor must
>carry + * all the desired key parameters, input and output pointers.
>+ */
>+#include 
>+#include 
>+#include "caam_rsapubkey-asn1.h"
>+#include "caam_rsaprivkey-asn1.h"
>+#include "compat.h"
>+#include "caampkc.h"
>+#include "sg_sw_sec4.h"
>+#include

[PATCH 2/3] crypto: scatterwalk - export scatterwalk_pagedone

2016-02-22 Thread Tudor Ambarus

Used in caam driver. Export the symbol since the caam driver
can be built as a module.

Signed-off-by: Tudor Ambarus 
---
 crypto/scatterwalk.c | 5 +++--
 include/crypto/scatterwalk.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index bc3222d..03d34f9 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -47,8 +47,8 @@ void *scatterwalk_map(struct scatter_walk *walk)
 }
 EXPORT_SYMBOL_GPL(scatterwalk_map);
 
-static void scatterwalk_pagedone(struct scatter_walk *walk, int out,
-unsigned int more)
+void scatterwalk_pagedone(struct scatter_walk *walk, int out,
+ unsigned int more)
 {
if (out) {
struct page *page;
@@ -69,6 +69,7 @@ static void scatterwalk_pagedone(struct scatter_walk *walk, 
int out,
scatterwalk_start(walk, sg_next(walk->sg));
}
 }
+EXPORT_SYMBOL_GPL(scatterwalk_pagedone);
 
 void scatterwalk_done(struct scatter_walk *walk, int out, int more)
 {
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 8b799c5..6535a20 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -89,6 +89,8 @@ void scatterwalk_copychunks(void *buf, struct scatter_walk 
*walk,
 void scatterwalk_sg_copychunks(struct scatter_walk *dest,
   struct scatter_walk *src, size_t nbytes);
 void *scatterwalk_map(struct scatter_walk *walk);
+void scatterwalk_pagedone(struct scatter_walk *walk, int out,
+ unsigned int more);
 void scatterwalk_done(struct scatter_walk *walk, int out, int more);
 
 void scatterwalk_map_and_copy(void *buf, struct scatterlist *sg,
-- 
1.8.3.1

--
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 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks

2016-02-22 Thread Tudor Ambarus

This patch adds the function scatterwalk_sg_copychunks which writes
a chunk of data from a scatterwalk to another scatterwalk.
It will be used by caam driver to remove the leading zeros of RSA's
algorithm output.

Signed-off-by: Tudor Ambarus 
---
 crypto/scatterwalk.c | 26 ++
 include/crypto/scatterwalk.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index ea5815c..bc3222d 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -125,6 +125,32 @@ void scatterwalk_map_and_copy(void *buf, struct 
scatterlist *sg,
 }
 EXPORT_SYMBOL_GPL(scatterwalk_map_and_copy);
 
+void scatterwalk_sg_copychunks(struct scatter_walk *dest,
+  struct scatter_walk *src, size_t nbytes)
+{
+   for (;;) {
+   unsigned int len_this_page = scatterwalk_pagelen(dest);
+   u8 *vaddr;
+
+   if (len_this_page > nbytes)
+   len_this_page = nbytes;
+
+   vaddr = scatterwalk_map(dest);
+   scatterwalk_copychunks(vaddr, src, len_this_page, 0);
+   scatterwalk_unmap(vaddr);
+
+   scatterwalk_advance(dest, len_this_page);
+
+   if (nbytes == len_this_page)
+   break;
+
+   nbytes -= len_this_page;
+
+   scatterwalk_pagedone(dest, 0, 1);
+   }
+}
+EXPORT_SYMBOL_GPL(scatterwalk_sg_copychunks);
+
 int scatterwalk_bytes_sglen(struct scatterlist *sg, int num_bytes)
 {
int offset = 0, n = 0;
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 35f99b6..8b799c5 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -86,6 +86,8 @@ static inline void scatterwalk_unmap(void *vaddr)
 void scatterwalk_start(struct scatter_walk *walk, struct scatterlist *sg);
 void scatterwalk_copychunks(void *buf, struct scatter_walk *walk,
size_t nbytes, int out);
+void scatterwalk_sg_copychunks(struct scatter_walk *dest,
+  struct scatter_walk *src, size_t nbytes);
 void *scatterwalk_map(struct scatter_walk *walk);
 void scatterwalk_done(struct scatter_walk *walk, int out, int more);
 
-- 
1.8.3.1

--
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: 3.14.61 breaks dm disk drive encryption?

3.14.61 breaks dm disk drive encryption?

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer

Re: [PATCH 0/8] X.509: Software public key subtype changes

RE: [PATCH 3/3] crypto: caam - add support for RSA algorithm

Re: [PATCH 3/3] crypto: caam - add support for RSA algorithm

[PATCH 2/3] crypto: scatterwalk - export scatterwalk_pagedone

[PATCH 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks

10 matches

Site Navigation

Mail list logo

Footer information