using crypto_digest() on non-kmalloc'd memory failures

using crypto_digest() on non-kmalloc'd memory failures

[Matt Domsch]

James, David,

Oleg noted that when we call crypto_digest() on memory allocated as a
static array in a module, rather than kmalloc(GFP_KERNEL), it returns
incorrect data, and with other functions, a kernel panic.

Thoughts as to why this may be?  Oleg's test patch appended.

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

----- Forwarded message from Oleg Makarenko <mole@quadra.ru> -----

From: Oleg Makarenko <mole@quadra.ru>
To: Matt Domsch <Matt_Domsch@dell.com>
CC: linux-ppp@vger.kernel.org, pptpclient-devel@lists.sourceforge.net
Subject: Re: [pptp-devel] Re: [2/2]: ppp_mppe inclusion
Date: Sun, 05 Sep 2004 22:23:15 +0400

>>>2.  For some reason you can not use non GFP_KERNEL memory and scatter 
>>>lists or at least mix them in crypto_digest().  That is why sha_pad is 
>>>now in struct state {}.
>
>Can you describe what happens when you do?

please try the attached patch for tcrypt.c to see what is going on 
yourself.  modprobe the resulting module with mode=2 parameter to test 
sha1 and see how it fails the tests (incorrect results, no kernel panic).

For mode=0 (or without any parameter) you should get kernel panic.

=oleg

--- tcrypt.c.orig	2004-08-14 09:37:38.000000000 +0400
+++ tcrypt.c	2004-09-05 21:11:19.000000000 +0400
@@ -58,6 +58,8 @@
 static char *xbuf;
 static char *tvmem;
 
+static char tvmem_buf[TVMEMSIZE];
+
 static char *check[] = {
 	"des", "md5", "des3_ede", "rot13", "sha1", "sha256", "blowfish",
 	"twofish", "serpent", "sha384", "sha512", "md4", "aes", "cast6", 
@@ -820,7 +822,8 @@
 static int __init
 init(void)
 {
-	tvmem = kmalloc(TVMEMSIZE, GFP_KERNEL);
+	tvmem = &tvmem_buf[0];
+
 	if (tvmem == NULL)
 		return -ENOMEM;
 
@@ -833,7 +836,6 @@
 	do_test();
 
 	kfree(xbuf);
-	kfree(tvmem);
 	return 0;
 }
 

Re: using crypto_digest() on non-kmalloc'd memory failures

[James Morris]

On Mon, 18 Oct 2004, Matt Domsch wrote:

> James, David,
> 
> Oleg noted that when we call crypto_digest() on memory allocated as a
> static array in a module, rather than kmalloc(GFP_KERNEL), it returns
> incorrect data, and with other functions, a kernel panic.
> 
> Thoughts as to why this may be?  Oleg's test patch appended.

I don't recall the exact details, but it's related to using kmap in the 
core crypto code.


- James
-- 
James Morris
<jmorris@redhat.com>

Re: using crypto_digest() on non-kmalloc'd memory failures

[Oleg Makarenko]

James Morris wrote:

>On Mon, 18 Oct 2004, Matt Domsch wrote:
>
>  
>
>>James, David,
>>
>>Oleg noted that when we call crypto_digest() on memory allocated as a
>>static array in a module, rather than kmalloc(GFP_KERNEL), it returns
>>incorrect data, and with other functions, a kernel panic.
>>
>>Thoughts as to why this may be?  Oleg's test patch appended.
>>    
>>
>
>I don't recall the exact details, but it's related to using kmap in the 
>core crypto code.
>
>
>- James
>  
>
So to calculate digest on some static data I need to copy them to 
kmalloc'ed memory first, right?

Can this copying be somehow avoided?

And one more question on crypto api. It looks like it is not very 
effective for a single byte "block" ciphers as arc4. The overhead is 
probably too big. Just look at the loop in cipher.c/crypt() and the code 
in arc4.c/arc4_crypt(). All this code is called for every single clear 
text byte. Right? Looks like an overkill for bsize == 1.

Is there any better way to use crypto api for arc4 or similar ciphers? 
Cipher block size is not always a natural choice for the crypto_yield(). 
Especially for fast ciphers (arc4) and small "block" sizes (arc4 again).

Or have I missed something obvious?

=oleg

Re: using crypto_digest() on non-kmalloc'd memory failures

[David S. Miller]

On Tue, 19 Oct 2004 00:05:41 +0400
Oleg Makarenko <mole@quadra.ru> wrote:

> So to calculate digest on some static data I need to copy them to 
> kmalloc'ed memory first, right?
> 
> Can this copying be somehow avoided?

It is necessary to be able to kmap() the data item
passed into the crypto layer, so dynamically allocated
memory obtained via kmalloc() or similar must be used.

Re: using crypto_digest() on non-kmalloc'd memory failures

[Brian Gerst]

Matt Domsch wrote:
> James, David,
> 
> Oleg noted that when we call crypto_digest() on memory allocated as a
> static array in a module, rather than kmalloc(GFP_KERNEL), it returns
> incorrect data, and with other functions, a kernel panic.
> 
> Thoughts as to why this may be?  Oleg's test patch appended.
> 

On some arches modules reside in vmalloc space.

--
				Brian Gerst

Re: using crypto_digest() on non-kmalloc'd memory failures

[Gene Heskett]

On Monday 18 October 2004 15:29, Matt Domsch wrote:
>James, David,
>
>Oleg noted that when we call crypto_digest() on memory allocated as
> a static array in a module, rather than kmalloc(GFP_KERNEL), it
> returns incorrect data, and with other functions, a kernel panic.
>
>Thoughts as to why this may be?  Oleg's test patch appended.

Off topic Matt, but why am I getting 4 to 6 copies of the messages you 
send?  All identical time stamps, the whole works.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

dupes (was Re: using crypto_digest() on non-kmalloc'd memory failures)

[Matt Domsch]

On Mon, Oct 18, 2004 at 06:10:41PM -0400, Gene Heskett wrote:
> Off topic Matt, but why am I getting 4 to 6 copies of the messages you 
> send?  All identical time stamps, the whole works.

I'm only sending one far as I can tell...
Has it happened for more than one message, and only from me?

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: using crypto_digest() on non-kmalloc'd memory failures

[James Morris]

On Tue, 19 Oct 2004, Oleg Makarenko wrote:

> And one more question on crypto api. It looks like it is not very 
> effective for a single byte "block" ciphers as arc4. The overhead is 
> probably too big. Just look at the loop in cipher.c/crypt() and the code 
> in arc4.c/arc4_crypt(). All this code is called for every single clear 
> text byte. Right? Looks like an overkill for bsize == 1.
> 
> Is there any better way to use crypto api for arc4 or similar ciphers? 
> Cipher block size is not always a natural choice for the crypto_yield(). 
> Especially for fast ciphers (arc4) and small "block" sizes (arc4 again).

ARC4 is a bit strange because it's a stream cipher.  I guess we could add 
another encryption mode 'stream' which is optimized for one byte at a time 
operation.


- James
-- 
James Morris
<jmorris@redhat.com>

Re: using crypto_digest() on non-kmalloc'd memory failures

[Oleg Makarenko]

James Morris wrote:

On Tue, 19 Oct 2004, Oleg Makarenko wrote:


>>Is there any better way to use crypto api for arc4 or similar ciphers? 
>>Cipher block size is not always a natural choice for the crypto_yield(). 
>>Especially for fast ciphers (arc4) and small "block" sizes (arc4 again).
>>    
>>
>
>ARC4 is a bit strange because it's a stream cipher.  I guess we could add 
>another encryption mode 'stream' which is optimized for one byte at a time 
>operation.
>
>
>- James
>  
>
That would probably require one more parameter to 
cin_encrypt/cia_decrypt, something like "nblocks" which currently is 
always 1 and one more struct crypto_alg field that would help upper 
level to decide how many blocks it can safely encrypt/decrypt() at a 
time before crypto_yield(). This value depends on algorithm speed and 
should be chosen to make overhead smaller. It could  be > 1 even for 
fast block ciphers and should be > 1 for stream ciphers.

=oleg