Re: [PATCH v3] x86, crypto: ported aes-ni implementation to x86
On 03.11.2010, 23:27 Huang Ying wrote: > On Wed, 2010-11-03 at 14:14 -0700, Mathias Krause wrote: >> The AES-NI instructions are also available in legacy mode so the 32-bit >> architecture may profit from those, too. >> >> To illustrate the performance gain here's a short summary of the tcrypt >> speed test on a Core i7 M620 running at 2.67GHz comparing both assembler >> implementations: >> >> x86: i568 aes-ni delta >> 256 bit, 8kB blocks, ECB: 125.94 MB/s 187.09 MB/s +48.6% > > Which method do you used for speed testing? > > modprobe tcrypt mode=200 sec= Yes. I used: modprobe tcrypt mode=200 sec=1 > That actually does not work very well for AES-NI. Because AES-NI > blkcipher is tested in synchronous mode, and in that mode, > kernel_fpu_begin/end() must be called for every block, and > kernel_fpu_begin/end() is quite slow. That's what I figured, too. Can this slowdown be avoided by saving and restoring the used FPU registers within the assembler implementation or would this be even slower? > At the same time, some further > optimization for AES-NI can not be tested (such as "ecb-aes-aesni" > driver) in that mode, because they are only available in asynchronous > mode. After finding the bug in the second version of the patch I noticed this, too. > When developing AES-NI for x86_64, I uses dm-crypt + AES-NI for speed > testing, where AES-NI blkcipher will be tested in asynchronous mode, and > kernel_fpu_begin/end() is called for every page. Can you use that to > test? But wouldn't this be even slower than the above measurement? I took the results for 8kB blocks and a page would only be 4kB ... well, depends on what kind of pages you took. IIRC x86-64 not only supports 2MB but also 1GB pages ;) > Or you can add test_acipher_speed (similar with test_ahash_speed) to > test cipher in asynchronous mode. Maybe I'll try this approach, since it looks like just a minor modification of the tcrypt module. Thanks for the hints! Best regards, Mathias > > Best Regards, > Huang Ying -- 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 v3] x86, crypto: ported aes-ni implementation to x86
On Thu, 2010-11-04 at 00:38 -0700, Mathias Krause wrote: > On 03.11.2010, 23:27 Huang Ying wrote: > > On Wed, 2010-11-03 at 14:14 -0700, Mathias Krause wrote: > >> The AES-NI instructions are also available in legacy mode so the 32-bit > >> architecture may profit from those, too. > >> > >> To illustrate the performance gain here's a short summary of the tcrypt > >> speed test on a Core i7 M620 running at 2.67GHz comparing both assembler > >> implementations: > >> > >> x86: i568 aes-ni delta > >> 256 bit, 8kB blocks, ECB: 125.94 MB/s 187.09 MB/s +48.6% > > > > Which method do you used for speed testing? > > > > modprobe tcrypt mode=200 sec= > > Yes. I used: modprobe tcrypt mode=200 sec=1 > > > That actually does not work very well for AES-NI. Because AES-NI > > blkcipher is tested in synchronous mode, and in that mode, > > kernel_fpu_begin/end() must be called for every block, and > > kernel_fpu_begin/end() is quite slow. > > That's what I figured, too. Can this slowdown be avoided by saving and > restoring the used FPU registers within the assembler implementation or > would this be even slower? That is a customized version of kernel_fpu_begin/end(), I think the x86 maintainer will not like it. And the benefit may be small too. > > At the same time, some further > > optimization for AES-NI can not be tested (such as "ecb-aes-aesni" > > driver) in that mode, because they are only available in asynchronous > > mode. > > After finding the bug in the second version of the patch I noticed this, > too. > > > When developing AES-NI for x86_64, I uses dm-crypt + AES-NI for speed > > testing, where AES-NI blkcipher will be tested in asynchronous mode, and > > kernel_fpu_begin/end() is called for every page. Can you use that to > > test? > > But wouldn't this be even slower than the above measurement? I took the > results for 8kB blocks and a page would only be 4kB ... well, depends on > what kind of pages you took. IIRC x86-64 not only supports 2MB but also > 1GB pages ;) There is other difference between them. In synchronous mode kernel_fpu_begin/end() is called for every block, while in asynchronous mode and dm-crypt, kernel_fpu_begin/end() is called for every page. So although the block size is smaller, the result will be better. > > Or you can add test_acipher_speed (similar with test_ahash_speed) to > > test cipher in asynchronous mode. > > Maybe I'll try this approach, since it looks like just a minor > modification of the tcrypt module. Thanks! Best Regards, Huang Ying -- 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: cast5: simplify if-statements
* Nicolas Kaiser :
> I noticed that by factoring out common rounds from the
> branches of the if-statements in the encryption and
> decryption functions, the executable file size goes down
> significantly, for crypto/cast5.ko from 26688 bytes
> to 24336 bytes (amd64).
>
> On my test system, I saw a slight speedup.
Hi there!
How would I add a simple cast5 cipher speed test to tcrypt.c, like this?
case 14:
test_cipher_speed("ecb(cast5)", ENCRYPT, sec, NULL, 0,
speed_template_8);
test_cipher_speed("ecb(cast5)", DECRYPT, sec, NULL, 0,
speed_template_8);
test_cipher_speed("cbc(cast5)", ENCRYPT, sec, NULL, 0,
speed_template_8);
test_cipher_speed("cbc(cast5)", DECRYPT, sec, NULL, 0,
speed_template_8);
break;
Does that make sense? Here are my results:
# insmod crypto/tcrypt.ko mode=14 sec=30
Before:
testing speed of ecb(cast5) encryption
test 0 (64 bit key, 16 byte blocks): 118241789 operations in 30 seconds
(1891868624 bytes)
test 1 (64 bit key, 64 byte blocks): 40502820 operations in 30 seconds
(2592180480 bytes)
test 2 (64 bit key, 256 byte blocks): 1145 operations in 30 seconds
(2844453120 bytes)
test 3 (64 bit key, 1024 byte blocks): 2858271 operations in 30 seconds
(2926869504 bytes)
test 4 (64 bit key, 8192 byte blocks): 359327 operations in 30 seconds
(2943606784 bytes)
testing speed of ecb(cast5) decryption
test 0 (64 bit key, 16 byte blocks): 118443232 operations in 30 seconds
(1895091712 bytes)
test 1 (64 bit key, 64 byte blocks): 40060571 operations in 30 seconds
(2563876544 bytes)
test 2 (64 bit key, 256 byte blocks): 10944717 operations in 30 seconds
(2801847552 bytes)
test 3 (64 bit key, 1024 byte blocks): 2811154 operations in 30 seconds
(2878621696 bytes)
test 4 (64 bit key, 8192 byte blocks): 353043 operations in 30 seconds
(2892128256 bytes)
testing speed of cbc(cast5) encryption
test 0 (64 bit key, 16 byte blocks): 110614202 operations in 30 seconds
(1769827232 bytes)
test 1 (64 bit key, 64 byte blocks): 37260496 operations in 30 seconds
(2384671744 bytes)
test 2 (64 bit key, 256 byte blocks): 10323268 operations in 30 seconds
(2642756608 bytes)
test 3 (64 bit key, 1024 byte blocks): 2650259 operations in 30 seconds
(2713865216 bytes)
test 4 (64 bit key, 8192 byte blocks): 333281 operations in 30 seconds
(2730237952 bytes)
testing speed of cbc(cast5) decryption
test 0 (64 bit key, 16 byte blocks): 102455488 operations in 30 seconds
(1639287808 bytes)
test 1 (64 bit key, 64 byte blocks): 35507599 operations in 30 seconds
(2272486336 bytes)
test 2 (64 bit key, 256 byte blocks): 9962653 operations in 30 seconds
(2550439168 bytes)
test 3 (64 bit key, 1024 byte blocks): 2569557 operations in 30 seconds
(2631226368 bytes)
test 4 (64 bit key, 8192 byte blocks): 323085 operations in 30 seconds
(2646712320 bytes)
that's in sum:
87993190 bytes/s
86877105 bytes/s
81609058 bytes/s
78267680 bytes/s
After:
testing speed of ecb(cast5) encryption
test 0 (64 bit key, 16 byte blocks): 120033632 operations in 30 seconds
(1920538112 bytes)
test 1 (64 bit key, 64 byte blocks): 41484473 operations in 30 seconds
(2655006272 bytes)
test 2 (64 bit key, 256 byte blocks): 11418041 operations in 30 seconds
(2923018496 bytes)
test 3 (64 bit key, 1024 byte blocks): 2940940 operations in 30 seconds
(3011522560 bytes)
test 4 (64 bit key, 8192 byte blocks): 369831 operations in 30 seconds
(302962 bytes)
testing speed of ecb(cast5) decryption
test 0 (64 bit key, 16 byte blocks): 122215696 operations in 30 seconds
(1955451136 bytes)
test 1 (64 bit key, 64 byte blocks): 41845591 operations in 30 seconds
(2678117824 bytes)
test 2 (64 bit key, 256 byte blocks): 11478322 operations in 30 seconds
(2938450432 bytes)
test 3 (64 bit key, 1024 byte blocks): 2952595 operations in 30 seconds
(3023457280 bytes)
test 4 (64 bit key, 8192 byte blocks): 371305 operations in 30 seconds
(3041730560 bytes)
testing speed of cbc(cast5) encryption
test 0 (64 bit key, 16 byte blocks): 112301700 operations in 30 seconds
(1796827200 bytes)
test 1 (64 bit key, 64 byte blocks): 38131586 operations in 30 seconds
(2440421504 bytes)
test 2 (64 bit key, 256 byte blocks): 10609299 operations in 30 seconds
(2715980544 bytes)
test 3 (64 bit key, 1024 byte blocks): 2728723 operations in 30 seconds
(2794212352 bytes)
test 4 (64 bit key, 8192 byte blocks): 343249 operations in 30 seconds
(2811895808 bytes)
testing speed of cbc(cast5) decryption
test 0 (64 bit key, 16 byte blocks): 106721453 operations in 30 seconds
(1707543248 bytes)
test 1 (64 bit key, 64 byte blocks): 3757 operations in 30 seconds
(2404693312 bytes)
test 2 (64 bit key, 256 byte blocks): 10624511 operations in 30 seconds
(2719874816 bytes)
test 3 (64 bit key, 1024 byte blocks): 2745305 operations in 30 seconds
(2
[PATCH 1/1] crypto: api.c: adding doxygen comments to api
Signed-off-by: Mark A. Allyn
---
crypto/api.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/crypto/api.c b/crypto/api.c
index 033a714..a11939f 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -193,6 +193,13 @@ static struct crypto_alg *crypto_larval_wait(struct
crypto_alg *alg)
return alg;
}
+/**
+ * This gets the crypto_alg structure for an algorithm
+ * it return struct crypto_alg
+ * @name: name of the algorithm
+ * @type: crypto type (defined at about line 31 of include/linux/crypto.h)
+ * @mask: mask of allowable crypto types
+ */
struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
@@ -205,6 +212,13 @@ struct crypto_alg *crypto_alg_lookup(const char *name, u32
type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alg_lookup);
+/**
+ * This gets the large value crypto_alg structure for an algorithm
+ * it return struct crypto_alg
+ * @name: name of the algorithm
+ * @type: crypto type (defined at about line 31 of include/linux/crypto.h)
+ * @mask: mask of allowable crypto types
+ */
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
--
1.6.3.3
--
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 1/1] crypto: api.c: adding doxygen comments to api
On Thu, 4 Nov 2010 09:32:42 -0700 Mark Allyn wrote:
> Signed-off-by: Mark A. Allyn
We use kernel-doc notation in kernel sources, not doxygen.
Please see Documentation/kernel-doc-nano-HOWTO.txt for info,
or ask me.
Thanks.
> ---
> crypto/api.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/crypto/api.c b/crypto/api.c
> index 033a714..a11939f 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -193,6 +193,13 @@ static struct crypto_alg *crypto_larval_wait(struct
> crypto_alg *alg)
> return alg;
> }
>
> +/**
> + * This gets the crypto_alg structure for an algorithm
> + * it return struct crypto_alg
> + * @name: name of the algorithm
> + * @type: crypto type (defined at about line 31 of include/linux/crypto.h)
> + * @mask: mask of allowable crypto types
> + */
> struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> @@ -205,6 +212,13 @@ struct crypto_alg *crypto_alg_lookup(const char *name,
> u32 type, u32 mask)
> }
> EXPORT_SYMBOL_GPL(crypto_alg_lookup);
>
> +/**
> + * This gets the large value crypto_alg structure for an algorithm
> + * it return struct crypto_alg
> + * @name: name of the algorithm
> + * @type: crypto type (defined at about line 31 of include/linux/crypto.h)
> + * @mask: mask of allowable crypto types
> + */
> struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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 1/1] crypto: api.c: adding doxygen comments to api
On 11/04/2010 09:32 AM, Mark Allyn wrote:
Subject: [PATCH 1/1] crypto: api.c: adding doxygen comments to api
Do we really use doxygen in the kernel? Perhaps a subject line
containing the string 'kernel-doc' would be more accurate.
Reading kernel-doc-nano-HOWTO.txt will show you the proper format.
Signed-off-by: Mark A. Allyn
---
crypto/api.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/crypto/api.c b/crypto/api.c
index 033a714..a11939f 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -193,6 +193,13 @@ static struct crypto_alg *crypto_larval_wait(struct
crypto_alg *alg)
return alg;
}
+/**
+ * This gets the crypto_alg structure for an algorithm
+ * it return struct crypto_alg
+ * @name: name of the algorithm
+ * @type: crypto type (defined at about line 31 of include/linux/crypto.h)
Referencing kernel source file line numbers in documentation seems like
an excellent way to have the documentation quickly be incorrect.
+ * @mask: mask of allowable crypto types
+ */
struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
@@ -205,6 +212,13 @@ struct crypto_alg *crypto_alg_lookup(const char *name, u32
type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alg_lookup);
+/**
+ * This gets the large value crypto_alg structure for an algorithm
+ * it return struct crypto_alg
+ * @name: name of the algorithm
+ * @type: crypto type (defined at about line 31 of include/linux/crypto.h)
+ * @mask: mask of allowable crypto types
+ */
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
--
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/1] crypto: api.c adding kernel-doc comments
Add comments to crypto_alg_lookup and crypto_larval_lookup
I am re-submitting this due to errors
Signed-off-by: Mark A. Allyn
---
crypto/api.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/crypto/api.c b/crypto/api.c
index 033a714..71c389d 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -193,6 +193,15 @@ static struct crypto_alg *crypto_larval_wait(struct
crypto_alg *alg)
return alg;
}
+/**
+ * crypto_alg_lookup() return crypto_alg structure for an algorithm
+ * @name: text string containing name of algorithm
+ * @type: crypto type (defined at about line 31 of
+ * include/linux/crypto.h)
+ * @mask: mask of allowable crypto types (use or'd list
+ * of types as defined at about line 31 of
+ * include/linux/crypto.h)
+ */
struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
@@ -205,6 +214,16 @@ struct crypto_alg *crypto_alg_lookup(const char *name, u32
type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alg_lookup);
+/**
+ * crypto_alg_larval lookup() return large value (larval) crypto_alg
+ * structure for an algorithm
+ * @name: text string containing name of algorithm
+ * @type: crypto type (defined at about line 31 of
+ * include/linux/crypto.h)
+ * @mask: mask of allowable crypto types (use or'd list
+ * of types as defined at about line 31 of
+ * include/linux/crypto.h)
+ */
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
--
1.6.3.3
--
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 1/1] crypto: api.c adding kernel-doc comments
On Thu, 4 Nov 2010 10:07:22 -0700 Mark Allyn wrote:
> Add comments to crypto_alg_lookup and crypto_larval_lookup
>
> I am re-submitting this due to errors
>
> Signed-off-by: Mark A. Allyn
> ---
> crypto/api.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/crypto/api.c b/crypto/api.c
> index 033a714..71c389d 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -193,6 +193,15 @@ static struct crypto_alg *crypto_larval_wait(struct
> crypto_alg *alg)
> return alg;
> }
>
> +/**
> + * crypto_alg_lookup() return crypto_alg structure for an algorithm
needs hyphen between function name and "return".
> + * @name:text string containing name of algorithm
> + * @type:crypto type (defined at about line 31 of
> + * include/linux/crypto.h)
> + * @mask:mask of allowable crypto types (use or'd list
> + * of types as defined at about line 31 of
> + * include/linux/crypto.h)
drop the line numbers...
> + */
> struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> @@ -205,6 +214,16 @@ struct crypto_alg *crypto_alg_lookup(const char *name,
> u32 type, u32 mask)
> }
> EXPORT_SYMBOL_GPL(crypto_alg_lookup);
>
> +/**
> + * crypto_alg_larval lookup() return large value (larval) crypto_alg
* crypto_larval_lookup() - return large value (larval) crypto_alg
> + * structure for an algorithm
> + * @name:text string containing name of algorithm
> + * @type:crypto type (defined at about line 31 of
> + * include/linux/crypto.h)
> + * @mask:mask of allowable crypto types (use or'd list
> + * of types as defined at about line 31 of
> + * include/linux/crypto.h)
> + */
drop the line numbers.
> struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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 1/1] crypto: api.c adding kernel-doc comments
This is my first time in attempting to patch documentation. Shall I follow your
suggestions by submitting a patch that depends on this patch or shall I submit
the whole thing again with the corrections?
Mark
-Original Message-
From: Randy Dunlap [mailto:rdun...@xenotime.net]
Sent: Thursday, November 04, 2010 10:22 AM
To: Allyn, Mark A
Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org
Subject: Re: [PATCH 1/1] crypto: api.c adding kernel-doc comments
On Thu, 4 Nov 2010 10:07:22 -0700 Mark Allyn wrote:
> Add comments to crypto_alg_lookup and crypto_larval_lookup
>
> I am re-submitting this due to errors
>
> Signed-off-by: Mark A. Allyn
> ---
> crypto/api.c | 19 +++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/crypto/api.c b/crypto/api.c
> index 033a714..71c389d 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -193,6 +193,15 @@ static struct crypto_alg *crypto_larval_wait(struct
> crypto_alg *alg)
> return alg;
> }
>
> +/**
> + * crypto_alg_lookup() return crypto_alg structure for an algorithm
needs hyphen between function name and "return".
> + * @name:text string containing name of algorithm
> + * @type:crypto type (defined at about line 31 of
> + * include/linux/crypto.h)
> + * @mask:mask of allowable crypto types (use or'd list
> + * of types as defined at about line 31 of
> + * include/linux/crypto.h)
drop the line numbers...
> + */
> struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> @@ -205,6 +214,16 @@ struct crypto_alg *crypto_alg_lookup(const char *name,
> u32 type, u32 mask)
> }
> EXPORT_SYMBOL_GPL(crypto_alg_lookup);
>
> +/**
> + * crypto_alg_larval lookup() return large value (larval) crypto_alg
* crypto_larval_lookup() - return large value (larval) crypto_alg
> + * structure for an algorithm
> + * @name:text string containing name of algorithm
> + * @type:crypto type (defined at about line 31 of
> + * include/linux/crypto.h)
> + * @mask:mask of allowable crypto types (use or'd list
> + * of types as defined at about line 31 of
> + * include/linux/crypto.h)
> + */
drop the line numbers.
> struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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 1/1] crypto: api.c adding kernel-doc comments
On Thu, 4 Nov 2010 11:25:06 -0600 Allyn, Mark A wrote:
> This is my first time in attempting to patch documentation. Shall I follow
> your suggestions by submitting a patch that depends on this patch or shall I
> submit the whole thing again with the corrections?
>
Hi Mark,
If your patch was already merged somewhere (even in an intermediate tree),
you should just send a partial/update patch, but in this case, since it hasn't
been merged anywhere (that I know of), I recommend sending a complete new patch.
Thanks.
>
> -Original Message-
> From: Randy Dunlap [mailto:rdun...@xenotime.net]
> Sent: Thursday, November 04, 2010 10:22 AM
> To: Allyn, Mark A
> Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org
> Subject: Re: [PATCH 1/1] crypto: api.c adding kernel-doc comments
>
> On Thu, 4 Nov 2010 10:07:22 -0700 Mark Allyn wrote:
>
> > Add comments to crypto_alg_lookup and crypto_larval_lookup
> >
> > I am re-submitting this due to errors
> >
> > Signed-off-by: Mark A. Allyn
> > ---
> > crypto/api.c | 19 +++
> > 1 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/crypto/api.c b/crypto/api.c
> > index 033a714..71c389d 100644
> > --- a/crypto/api.c
> > +++ b/crypto/api.c
> > @@ -193,6 +193,15 @@ static struct crypto_alg *crypto_larval_wait(struct
> > crypto_alg *alg)
> > return alg;
> > }
> >
> > +/**
> > + * crypto_alg_lookup() return crypto_alg structure for an algorithm
>
> needs hyphen between function name and "return".
>
> > + * @name: text string containing name of algorithm
> > + * @type: crypto type (defined at about line 31 of
> > + * include/linux/crypto.h)
> > + * @mask: mask of allowable crypto types (use or'd list
> > + * of types as defined at about line 31 of
> > + * include/linux/crypto.h)
>
> drop the line numbers...
>
> > + */
> > struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
> > {
> > struct crypto_alg *alg;
> > @@ -205,6 +214,16 @@ struct crypto_alg *crypto_alg_lookup(const char *name,
> > u32 type, u32 mask)
> > }
> > EXPORT_SYMBOL_GPL(crypto_alg_lookup);
> >
> > +/**
> > + * crypto_alg_larval lookup() return large value (larval) crypto_alg
>
> * crypto_larval_lookup() - return large value (larval) crypto_alg
>
>
> > + * structure for an algorithm
> > + * @name: text string containing name of algorithm
> > + * @type: crypto type (defined at about line 31 of
> > + * include/linux/crypto.h)
> > + * @mask: mask of allowable crypto types (use or'd list
> > + * of types as defined at about line 31 of
> > + * include/linux/crypto.h)
> > + */
>
> drop the line numbers.
>
> > struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32
> > mask)
> > {
> > struct crypto_alg *alg;
> > --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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: RFC: Crypto API User-interface
On Tue, Oct 19, 2010 at 09:44:18PM +0800, Herbert Xu wrote: > > OK I've gone ahead and implemented the user-space API for hashes > and ciphers. Here is a revised series with bug fixes and improvements. The main change is that hashes can now be finalised by recvmsg instead of requiring a preceding sendmsg with no MSG_MORE. Thakns to Miloslav Trmac for reviewing this and contributing fixes and improvements. 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
[PATCH 1/4] net - Add AF_ALG macros
net - Add AF_ALG macros
This patch adds the socket family/level macros for the yet-to-be-born
AF_ALG family. The AF_ALG family provides the user-space interface
for the kernel crypto API.
Signed-off-by: Herbert Xu
---
include/linux/socket.h |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 5146b50..ebc081b 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -193,7 +193,8 @@ struct ucred {
#define AF_PHONET 35 /* Phonet sockets */
#define AF_IEEE802154 36 /* IEEE802154 sockets */
#define AF_CAIF37 /* CAIF sockets */
-#define AF_MAX 38 /* For now.. */
+#define AF_ALG 38 /* Algorithm sockets*/
+#define AF_MAX 39 /* For now.. */
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
@@ -234,6 +235,7 @@ struct ucred {
#define PF_PHONET AF_PHONET
#define PF_IEEE802154 AF_IEEE802154
#define PF_CAIFAF_CAIF
+#define PF_ALG AF_ALG
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
@@ -307,6 +309,7 @@ struct ucred {
#define SOL_RDS276
#define SOL_IUCV 277
#define SOL_CAIF 278
+#define SOL_ALG279
/* IPX options */
#define IPX_TYPE 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 2/4] crypto: af_alg - User-space interface for Crypto API
crypto: af_alg - User-space interface for Crypto API
This patch creates the backbone of the user-space interface for
the Crypto API, through a new socket family AF_ALG.
Each session corresponds to one or more connections obtained from
that socket. The number depends on the number of inputs/outputs
of that particular type of operation. For most types there will
be a s ingle connection/file descriptor that is used for both input
and output. AEAD is one of the few that require two inputs.
Each algorithm type will provide its own implementation that plugs
into af_alg. They're keyed using a string such as "skcipher" or
"hash".
IOW this patch only contains the boring bits that is required
to hold everything together.
Thakns to Miloslav Trmac for reviewing this and contributing
fixes and improvements.
Signed-off-by: Herbert Xu
---
crypto/Kconfig |3
crypto/Makefile |1
crypto/af_alg.c | 460
include/crypto/if_alg.h | 92 +
include/linux/if_alg.h | 40
5 files changed, 596 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index e4bac29..357e3ca 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -841,6 +841,9 @@ config CRYPTO_ANSI_CPRNG
ANSI X9.31 A.2.4. Note that this option must be enabled if
CRYPTO_FIPS is selected
+config CRYPTO_USER_API
+ tristate
+
source "drivers/crypto/Kconfig"
endif # if CRYPTO
diff --git a/crypto/Makefile b/crypto/Makefile
index 423b7de..0b13197 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_CRYPTO_RNG2) += krng.o
obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o
obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
+obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
#
# generic algorithms and the async_tx api
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
new file mode 100644
index 000..92cd9b1
--- /dev/null
+++ b/crypto/af_alg.c
@@ -0,0 +1,460 @@
+/*
+ * af_alg: User-space algorithm interface
+ *
+ * This file provides the user-space API for algorithms.
+ *
+ * Copyright (c) 2010 Herbert Xu
+ *
+ * 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
+
+struct alg_type_list {
+ const struct af_alg_type *type;
+ struct list_head list;
+};
+
+static atomic_t alg_memory_allocated;
+
+static struct proto alg_proto = {
+ .name = "ALG",
+ .owner = THIS_MODULE,
+ .memory_allocated = &alg_memory_allocated,
+ .obj_size = sizeof(struct alg_sock),
+};
+
+static LIST_HEAD(alg_types);
+static DECLARE_RWSEM(alg_types_sem);
+
+static const struct af_alg_type *alg_get_type(const char *name)
+{
+ const struct af_alg_type *type = ERR_PTR(-ENOENT);
+ struct alg_type_list *node;
+
+ down_read(&alg_types_sem);
+ list_for_each_entry(node, &alg_types, list) {
+ if (strcmp(node->type->name, name))
+ continue;
+
+ if (try_module_get(node->type->owner))
+ type = node->type;
+ break;
+ }
+ up_read(&alg_types_sem);
+
+ return type;
+}
+
+int af_alg_register_type(const struct af_alg_type *type)
+{
+ struct alg_type_list *node;
+ int err = -EEXIST;
+
+ down_write(&alg_types_sem);
+ list_for_each_entry(node, &alg_types, list) {
+ if (!strcmp(node->type->name, type->name))
+ goto unlock;
+ }
+
+ node = kmalloc(sizeof(*node), GFP_KERNEL);
+ err = -ENOMEM;
+ if (!node)
+ goto unlock;
+
+ type->ops->owner = THIS_MODULE;
+ node->type = type;
+ list_add(&node->list, &alg_types);
+ err = 0;
+
+unlock:
+ up_write(&alg_types_sem);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(af_alg_register_type);
+
+int af_alg_unregister_type(const struct af_alg_type *type)
+{
+ struct alg_type_list *node;
+ int err = -ENOENT;
+
+ down_write(&alg_types_sem);
+ list_for_each_entry(node, &alg_types, list) {
+ if (strcmp(node->type->name, type->name))
+ continue;
+
+ list_del(&node->list);
+ kfree(node);
+ err = 0;
+ break;
+ }
+ up_write(&alg_types_sem);
+
+ return err;
+}
+EXPORT_SYMBOL_GPL(af_alg_unregister_type);
+
+static void alg_do_release(const struct af_alg_type *type, void *private)
+{
+ if (!type)
+ return;
+
+ type->release(private);
+ module_put(type->owner);
+}
+
+int af_alg_release(struct socket *sock)
[PATCH 4/4] crypto: algif_skcipher - User-space interface for skcipher operations
crypto: algif_skcipher - User-space interface for skcipher operations
This patch adds the af_alg plugin for symmetric key ciphers,
corresponding to the ablkcipher kernel operation type.
Keys can optionally be set through the setsockopt interface.
Once a sendmsg call occurs without MSG_MORE no further writes
may be made to the socket until all previous data has been read.
IVs and and whether encryption/decryption is performed can be
set through the setsockopt interface or as a control message
to sendmsg.
The interface is completely synchronous, all operations are
carried out in recvmsg(2) and will complete prior to the system
call returning.
The splice(2) interface support reading the user-space data directly
without copying (except that the Crypto API itself may copy the data
if alignment is off).
The recvmsg(2) interface supports directly writing to user-space
without additional copying, i.e., the kernel crypto interface will
receive the user-space address as its output SG list.
Thakns to Miloslav Trmac for reviewing this and contributing
fixes and improvements.
Signed-off-by: Herbert Xu
---
crypto/Kconfig |8
crypto/Makefile |1
crypto/algif_skcipher.c | 647
3 files changed, 656 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 6db27d7..69437e2 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -852,6 +852,14 @@ config CRYPTO_USER_API_HASH
This option enables the user-spaces interface for hash
algorithms.
+config CRYPTO_USER_API_SKCIPHER
+ tristate "User-space interface for symmetric key cipher algorithms"
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_USER_API
+ help
+ This option enables the user-spaces interface for symmetric
+ key cipher algorithms.
+
source "drivers/crypto/Kconfig"
endif # if CRYPTO
diff --git a/crypto/Makefile b/crypto/Makefile
index 14ab405..efc0f18 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
+obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
#
# generic algorithms and the async_tx api
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
new file mode 100644
index 000..abc15b2
--- /dev/null
+++ b/crypto/algif_skcipher.c
@@ -0,0 +1,647 @@
+/*
+ * algif_skcipher: User-space interface for skcipher algorithms
+ *
+ * This file provides the user-space API for symmetric key ciphers.
+ *
+ * Copyright (c) 2010 Herbert Xu
+ *
+ * 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
+
+struct skcipher_sg_list {
+ struct list_head list;
+
+ int cur;
+
+ struct scatterlist sg[0];
+};
+
+struct skcipher_ctx {
+ struct list_head tsgl;
+ struct af_alg_sgl rsgl;
+
+ void *iv;
+
+ struct af_alg_completion completion;
+
+ unsigned used;
+
+ unsigned int len;
+ bool more;
+ bool merge;
+ bool enc;
+
+ struct ablkcipher_request req;
+};
+
+#define MAX_SGL_ENTS ((PAGE_SIZE - sizeof(struct skcipher_sg_list)) / \
+ sizeof(struct scatterlist) - 1)
+
+static inline bool skcipher_writable(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct skcipher_ctx *ctx = ask->private;
+
+ return ctx->used + PAGE_SIZE <= max_t(int, sk->sk_sndbuf, PAGE_SIZE);
+}
+
+static int skcipher_alloc_sgl(struct sock *sk, int size)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct skcipher_ctx *ctx = ask->private;
+ struct skcipher_sg_list *sgl;
+ struct scatterlist *sg = NULL;
+
+ sgl = list_first_entry(&ctx->tsgl, struct skcipher_sg_list, list);
+ if (!list_empty(&ctx->tsgl))
+ sg = sgl->sg;
+
+ if (!sg || sgl->cur >= MAX_SGL_ENTS) {
+ sgl = sock_kmalloc(sk, sizeof(*sgl) +
+ sizeof(sgl->sg[0]) * (MAX_SGL_ENTS + 1),
+ GFP_KERNEL);
+ if (!sgl)
+ return -ENOMEM;
+
+ sg_init_table(sgl->sg, MAX_SGL_ENTS + 1);
+ sgl->cur = 0;
+
+ if (sg)
+ sg_chain(sg, MAX_SGL_ENTS + 1, sgl->sg);
+
+ list_add_tail(&sgl->list, &ctx->tsgl);
+ }
+
+ return 0;
+}
+
+static void skcipher_pull_sgl(struct sock *sk, int used)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct skcipher_ctx *ctx = ask->private;
+ struct skcipher_sg_list *sgl;
+ struct sc
[PATCH 3/4] crypto: algif_hash - User-space interface for hash operations
crypto: algif_hash - User-space interface for hash operations
This patch adds the af_alg plugin for hash, corresponding to
the ahash kernel operation type.
Keys can optionally be set through the setsockopt interface.
Each sendmsg call will finalise the hash unless sent with a MSG_MORE
flag.
Partial hash states can be cloned using accept(2).
The interface is completely synchronous, all operations will
complete prior to the system call returning.
Both sendmsg(2) and splice(2) support reading the user-space
data directly without copying (except that the Crypto API itself
may copy the data if alignment is off).
For now only the splice(2) interface supports performing digest
instead of init/update/final. In future the sendmsg(2) interface
will also be modified to use digest/finup where possible so that
hardware that cannot return a partial hash state can still benefit
from this interface.
Thakns to Miloslav Trmac for reviewing this and contributing
fixes and improvements.
Signed-off-by: Herbert Xu
---
crypto/Kconfig |8 +
crypto/Makefile |1
crypto/algif_hash.c | 321
3 files changed, 330 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 357e3ca..6db27d7 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -844,6 +844,14 @@ config CRYPTO_ANSI_CPRNG
config CRYPTO_USER_API
tristate
+config CRYPTO_USER_API_HASH
+ tristate "User-space interface for hash algorithms"
+ select CRYPTO_HASH
+ select CRYPTO_USER_API
+ help
+ This option enables the user-spaces interface for hash
+ algorithms.
+
source "drivers/crypto/Kconfig"
endif # if CRYPTO
diff --git a/crypto/Makefile b/crypto/Makefile
index 0b13197..14ab405 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o
obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
+obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
#
# generic algorithms and the async_tx api
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
new file mode 100644
index 000..014ea43
--- /dev/null
+++ b/crypto/algif_hash.c
@@ -0,0 +1,321 @@
+/*
+ * algif_hash: User-space interface for hash algorithms
+ *
+ * This file provides the user-space API for hash algorithms.
+ *
+ * Copyright (c) 2010 Herbert Xu
+ *
+ * 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
+
+struct hash_ctx {
+ struct af_alg_sgl sgl;
+
+ u8 *result;
+
+ struct af_alg_completion completion;
+
+ unsigned int len;
+ int err;
+ bool more;
+
+ struct ahash_request req;
+};
+
+static int hash_sendmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t ignored)
+{
+ int limit = ALG_MAX_PAGES * PAGE_SIZE;
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct hash_ctx *ctx = ask->private;
+ unsigned long iovlen;
+ struct iovec *iov;
+ long copied = 0;
+ int err;
+
+ if (limit > sk->sk_sndbuf)
+ limit = sk->sk_sndbuf;
+
+ lock_sock(sk);
+ if (!ctx->more) {
+ err = crypto_ahash_init(&ctx->req);
+ if (err)
+ goto unlock;
+ }
+
+ ctx->more = 0;
+
+ for (iov = msg->msg_iov, iovlen = msg->msg_iovlen; iovlen > 0;
+iovlen--, iov++) {
+ unsigned long seglen = iov->iov_len;
+ char __user *from = iov->iov_base;
+
+ while (seglen) {
+ int len = min_t(unsigned long, seglen, limit);
+ int newlen;
+
+ newlen = af_alg_make_sg(&ctx->sgl, from, len, 0);
+ if (newlen < 0)
+ goto unlock;
+
+ ahash_request_set_crypt(&ctx->req, ctx->sgl.sg, NULL,
+ newlen);
+
+ err = af_alg_wait_for_completion(
+ crypto_ahash_update(&ctx->req),
+ &ctx->completion);
+
+ af_alg_free_sg(&ctx->sgl);
+
+ if (err)
+ goto unlock;
+
+ seglen -= newlen;
+ from += newlen;
+ copied += newlen;
+ }
+ }
+
+ err = 0;
+
+ ctx->more = msg->msg_flags & MSG_MORE;
+ if (!ctx->more) {
+ ahash_request_set_crypt(&ctx->req, NULL, ctx->result, 0);
+
[PATCH] crypto: padlock: fix for non-64byte aligned data
Using cryptodev-linux with it's zero-copy functionality, one is mighty
enough to pass various misaligned/mis-sized buffers unmodified to the
engine's driver, which occured to be an easy way to break padlock
equipped machines:
On one hand, the original code is broken in padlock_xcrypt_cbc(): when
passing the "initial" bytes to xcryptcbc, 'count' is incorrectly used as
length. This may trigger prefetch-related issues, but will definitely
lead to data corruption as xcryptcbc is called again afterwards,
altering (count - initial) * AES_BLOCK_SIZE bytes after the end of
'output' in memory.
Another problem occurs when passing non-64byte aligned buffers, which
leads to memory corruption in userspace (running applications crash
randomly). This problem is too subtile for me to have more than vague
assumptions about it's origin. Anyways, this patch fixes them:
Instead of handling the "odd" bytes (i.e., the remainder when dividing
into prefetch blocks of 64bytes) at the beginning, go for them in the
end, copying the data out if prefetching would run beyond the page
boundary.
Signed-off-by: Phil Sutter
Signed-off-by: Nico Erfurth
---
drivers/crypto/padlock-aes.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 2e992bc..b3f3382 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -260,19 +260,14 @@ static inline void padlock_xcrypt_ecb(const u8 *input, u8
*output, void *key,
{
u32 initial = count & (ecb_fetch_blocks - 1);
- if (count < ecb_fetch_blocks) {
- ecb_crypt(input, output, key, control_word, count);
- return;
- }
-
- if (initial)
+ if (count > initial) {
asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep
xcryptecb */
: "+S"(input), "+D"(output)
- : "d"(control_word), "b"(key), "c"(initial));
+ : "d"(control_word), "b"(key), "c"(count -
initial));
+ }
- asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */
- : "+S"(input), "+D"(output)
- : "d"(control_word), "b"(key), "c"(count - initial));
+ if (initial)
+ ecb_crypt(input, output, key, control_word, initial);
}
static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void *key,
@@ -280,17 +275,15 @@ static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8
*output, void *key,
{
u32 initial = count & (cbc_fetch_blocks - 1);
- if (count < cbc_fetch_blocks)
- return cbc_crypt(input, output, key, iv, control_word, count);
-
- if (initial)
+ if (count > initial) {
asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" /* rep
xcryptcbc */
: "+S" (input), "+D" (output), "+a" (iv)
- : "d" (control_word), "b" (key), "c" (count));
+ : "d" (control_word), "b" (key), "c" (count -
initial));
+ }
+
+ if (initial)
+ return cbc_crypt(input, output, key, iv, control_word, initial);
- asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" /* rep xcryptcbc */
- : "+S" (input), "+D" (output), "+a" (iv)
- : "d" (control_word), "b" (key), "c" (count-initial));
return iv;
}
--
1.7.3.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: RFC: Crypto API User-interface
On Thu, Nov 04, 2010 at 01:43:16PM -0400, Miloslav Trmac wrote:
>
> shash_async_import() - it assumes that the struct shash_desc placed in
> ahash_request_ctx() of the struct ahash_request was initialized to point to
> the tfm, which is only done in shash_async_init().
Thanks for catching this. This patch should fix the problem.
commit 8850e3641dcc7446628681bd7c5f771005e0b208
Author: Herbert Xu
Date: Thu Nov 4 13:00:22 2010 -0500
crypto: hash - Fix async import on shash algorithm
The function shash_async_import did not initialise the descriptor
correctly prior to calling the underlying shash import function.
This patch adds the required initialisation.
Reported-by: Miloslav Trmac
Signed-off-by: Herbert Xu
diff --git a/crypto/shash.c b/crypto/shash.c
index 22fd943..76f74b9 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -310,7 +310,13 @@ static int shash_async_export(struct ahash_request *req,
void *out)
static int shash_async_import(struct ahash_request *req, const void *in)
{
- return crypto_shash_import(ahash_request_ctx(req), in);
+ struct crypto_shash **ctx = crypto_ahash_ctx(crypto_ahash_reqtfm(req));
+ struct shash_desc *desc = ahash_request_ctx(req);
+
+ desc->tfm = *ctx;
+ desc->flags = req->base.flags;
+
+ return crypto_shash_import(desc, in);
}
static void crypto_exit_shash_ops_async(struct crypto_tfm *tfm)
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: [PATCH] crypto: padlock: fix for non-64byte aligned data
On Thu, Nov 04, 2010 at 05:50:36PM +, Phil Sutter wrote:
> Using cryptodev-linux with it's zero-copy functionality, one is mighty
> enough to pass various misaligned/mis-sized buffers unmodified to the
> engine's driver, which occured to be an easy way to break padlock
> equipped machines:
OK.
> On one hand, the original code is broken in padlock_xcrypt_cbc(): when
> passing the "initial" bytes to xcryptcbc, 'count' is incorrectly used as
> length. This may trigger prefetch-related issues, but will definitely
> lead to data corruption as xcryptcbc is called again afterwards,
> altering (count - initial) * AES_BLOCK_SIZE bytes after the end of
> 'output' in memory.
Ouch, does the attached patch fix this problem for you?
> Another problem occurs when passing non-64byte aligned buffers, which
> leads to memory corruption in userspace (running applications crash
> randomly). This problem is too subtile for me to have more than vague
> assumptions about it's origin. Anyways, this patch fixes them:
I'd like to determine whether this is due to the previous bug.
If it still crashes randomly even with my one-line patch please
let me know.
> Instead of handling the "odd" bytes (i.e., the remainder when dividing
> into prefetch blocks of 64bytes) at the beginning, go for them in the
> end, copying the data out if prefetching would run beyond the page
> boundary.
I'd like to avoid this copying unless the hardware really needs
it.
Can you provide some information on the CPU where you're seeing
this?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
commit c054a076a1bd4731820a9c4d638b13d5c9bf5935
Author: Herbert Xu
Date: Thu Nov 4 14:38:39 2010 -0400
crypto: padlock - Fix AES-CBC handling on odd-block-sized input
On certain VIA chipsets AES-CBC requires the input/output to be
a multiple of 64 bytes. We had a workaround for this but it was
buggy as it sent the whole input for processing when it is meant
to only send the initial number of blocks which makes the rest
a multiple of 64 bytes.
As expected this causes memory corruption whenever the workaround
kicks in.
Reported-by: Phil Sutter
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 2e992bc..8a515ba 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -286,7 +286,7 @@ static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8
*output, void *key,
if (initial)
asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" /* rep
xcryptcbc */
: "+S" (input), "+D" (output), "+a" (iv)
- : "d" (control_word), "b" (key), "c" (count));
+ : "d" (control_word), "b" (key), "c" (initial));
asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" /* rep xcryptcbc */
: "+S" (input), "+D" (output), "+a" (iv)
--
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: cast5: simplify if-statements
On Wed, Oct 27, 2010 at 12:03:24PM +0200, Nicolas Kaiser wrote: > I noticed that by factoring out common rounds from the > branches of the if-statements in the encryption and > decryption functions, the executable file size goes down > significantly, for crypto/cast5.ko from 26688 bytes > to 24336 bytes (amd64). Patch applied. Thanks a lot! -- 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 2/3] RFC4106 AES-GCM Driver Using Intel New Instructions
On Thu, Oct 28, 2010 at 04:19:09PM +0100, tadeusz.st...@intel.com wrote: > Hi Herbert, >We have reworked the assembly to use macros instead of the new aesni > instructions. Both applied. Thanks for your efforts! >Do you think it is possible to get it in into 2.6.37? Sorry, it needed to have been ready much earlier to make this merge window. 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: [PATCH 1/4] net - Add AF_ALG macros
From: Herbert Xu Date: Thu, 04 Nov 2010 12:36:19 -0500 > net - Add AF_ALG macros > > This patch adds the socket family/level macros for the yet-to-be-born > AF_ALG family. The AF_ALG family provides the user-space interface > for the kernel crypto API. > > Signed-off-by: Herbert Xu Acked-by: David S. Miller -- 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 2/4] crypto: af_alg - User-space interface for Crypto API
From: Herbert Xu Date: Thu, 04 Nov 2010 12:36:19 -0500 > crypto: af_alg - User-space interface for Crypto API > > This patch creates the backbone of the user-space interface for > the Crypto API, through a new socket family AF_ALG. > > Each session corresponds to one or more connections obtained from > that socket. The number depends on the number of inputs/outputs > of that particular type of operation. For most types there will > be a s ingle connection/file descriptor that is used for both input > and output. AEAD is one of the few that require two inputs. > > Each algorithm type will provide its own implementation that plugs > into af_alg. They're keyed using a string such as "skcipher" or > "hash". > > IOW this patch only contains the boring bits that is required > to hold everything together. > > Thakns to Miloslav Trmac for reviewing this and contributing > fixes and improvements. > > Signed-off-by: Herbert Xu Acked-by: David S. Miller -- 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/4] crypto: algif_hash - User-space interface for hash operations
From: Herbert Xu Date: Thu, 04 Nov 2010 12:36:19 -0500 > crypto: algif_hash - User-space interface for hash operations > > This patch adds the af_alg plugin for hash, corresponding to > the ahash kernel operation type. > > Keys can optionally be set through the setsockopt interface. > > Each sendmsg call will finalise the hash unless sent with a MSG_MORE > flag. > > Partial hash states can be cloned using accept(2). > > The interface is completely synchronous, all operations will > complete prior to the system call returning. > > Both sendmsg(2) and splice(2) support reading the user-space > data directly without copying (except that the Crypto API itself > may copy the data if alignment is off). > > For now only the splice(2) interface supports performing digest > instead of init/update/final. In future the sendmsg(2) interface > will also be modified to use digest/finup where possible so that > hardware that cannot return a partial hash state can still benefit > from this interface. > > Thakns to Miloslav Trmac for reviewing this and contributing > fixes and improvements. > > Signed-off-by: Herbert Xu Acked-by: David S. Miller -- 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/4] crypto: algif_skcipher - User-space interface for skcipher operations
From: Herbert Xu Date: Thu, 04 Nov 2010 12:36:20 -0500 > crypto: algif_skcipher - User-space interface for skcipher operations > > This patch adds the af_alg plugin for symmetric key ciphers, > corresponding to the ablkcipher kernel operation type. > > Keys can optionally be set through the setsockopt interface. > > Once a sendmsg call occurs without MSG_MORE no further writes > may be made to the socket until all previous data has been read. > > IVs and and whether encryption/decryption is performed can be > set through the setsockopt interface or as a control message > to sendmsg. > > The interface is completely synchronous, all operations are > carried out in recvmsg(2) and will complete prior to the system > call returning. > > The splice(2) interface support reading the user-space data directly > without copying (except that the Crypto API itself may copy the data > if alignment is off). > > The recvmsg(2) interface supports directly writing to user-space > without additional copying, i.e., the kernel crypto interface will > receive the user-space address as its output SG list. > > Thakns to Miloslav Trmac for reviewing this and contributing > fixes and improvements. > > Signed-off-by: Herbert Xu Acked-by: David S. Miller -- 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/1] crypto: api.c: add comments to crypto_alg_lookup and crypto_alg_larval_lookup
This is resubmitted due to errors in style
Signed-off-by: Mark A. Allyn
---
crypto/api.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/crypto/api.c b/crypto/api.c
index 033a714..0314083 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -193,6 +193,13 @@ static struct crypto_alg *crypto_larval_wait(struct
crypto_alg *alg)
return alg;
}
+/**
+ * crypto_alg_lookup() - return crypto_alg structure for an algorithm
+ * @name: text string containing name of algorithm
+ * @type: crypto type defined in include/linux/crypto.h
+ * @mask: mask of allowable crypto types (use or'd list
+ * of types as defined in include/linux/crypto.h)
+ */
struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
@@ -205,6 +212,14 @@ struct crypto_alg *crypto_alg_lookup(const char *name, u32
type, u32 mask)
}
EXPORT_SYMBOL_GPL(crypto_alg_lookup);
+/**
+ * crypto_alg_larval_lookup() - returns large value (larval) crypto_alg
+ * structure for an algorithm
+ * @name: text string containing name of algorithm
+ * @type: crypto type defined in include/linux/crypto.h
+ * @mask: mask of allowable crypto types (use or'd list
+ * of types as defined in include/linux/crypto.h)
+ */
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
{
struct crypto_alg *alg;
--
1.6.3.3
--
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 1/1] crypto: api.c: add comments to crypto_alg_lookup and crypto_alg_larval_lookup
On Thu, 4 Nov 2010 12:49:48 -0700 Mark Allyn wrote:
> This is resubmitted due to errors in style
>
> Signed-off-by: Mark A. Allyn
> ---
> crypto/api.c | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/crypto/api.c b/crypto/api.c
> index 033a714..0314083 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -193,6 +193,13 @@ static struct crypto_alg *crypto_larval_wait(struct
> crypto_alg *alg)
> return alg;
> }
>
> +/**
> + * crypto_alg_lookup() - return crypto_alg structure for an algorithm
> + * @name:text string containing name of algorithm
> + * @type:crypto type defined in include/linux/crypto.h
> + * @mask:mask of allowable crypto types (use or'd list
> + * of types as defined in include/linux/crypto.h)
> + */
> struct crypto_alg *crypto_alg_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> @@ -205,6 +212,14 @@ struct crypto_alg *crypto_alg_lookup(const char *name,
> u32 type, u32 mask)
> }
> EXPORT_SYMBOL_GPL(crypto_alg_lookup);
>
> +/**
> + * crypto_alg_larval_lookup() - returns large value (larval) crypto_alg
> + * structure for an algorithm
That function name still does not match the actual name below.
> + * @name:text string containing name of algorithm
> + * @type:crypto type defined in include/linux/crypto.h
> + * @mask:mask of allowable crypto types (use or'd list
> + * of types as defined in include/linux/crypto.h)
> + */
> struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
> {
> struct crypto_alg *alg;
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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 06/49] crypto: Use vzalloc
Signed-off-by: Joe Perches
---
crypto/deflate.c |3 +--
crypto/zlib.c|3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 463dc85..cbc7a33 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -48,12 +48,11 @@ static int deflate_comp_init(struct deflate_ctx *ctx)
int ret = 0;
struct z_stream_s *stream = &ctx->comp_stream;
- stream->workspace = vmalloc(zlib_deflate_workspacesize());
+ stream->workspace = vzalloc(zlib_deflate_workspacesize());
if (!stream->workspace) {
ret = -ENOMEM;
goto out;
}
- memset(stream->workspace, 0, zlib_deflate_workspacesize());
ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
-DEFLATE_DEF_WINBITS, DEFLATE_DEF_MEMLEVEL,
Z_DEFAULT_STRATEGY);
diff --git a/crypto/zlib.c b/crypto/zlib.c
index c3015733..739b8fc 100644
--- a/crypto/zlib.c
+++ b/crypto/zlib.c
@@ -95,11 +95,10 @@ static int zlib_compress_setup(struct crypto_pcomp *tfm,
void *params,
zlib_comp_exit(ctx);
workspacesize = zlib_deflate_workspacesize();
- stream->workspace = vmalloc(workspacesize);
+ stream->workspace = vzalloc(workspacesize);
if (!stream->workspace)
return -ENOMEM;
- memset(stream->workspace, 0, workspacesize);
ret = zlib_deflateInit2(stream,
tb[ZLIB_COMP_LEVEL]
? nla_get_u32(tb[ZLIB_COMP_LEVEL])
--
1.7.3.1.g432b3.dirty
--
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
