Thread (7 messages) 7 messages, 2 authors, 2012-11-19

Re: Crypto causes panic in scatterwalk_done with large/multiple buffers

From: Jorgen Lundman <hidden>
Date: 2012-11-18 00:29:09

Appearently this patch only fixed my debug printk loop that used sg_next
from scatterlist API instead of scatterwalk_sg_next from scatterwalk API.
Sorry for the noise.
Thanks for looking at this. I think I am dealing with 2 problems, one is
that occasionally my buffers are from vmalloc, and needs to have some logic
using vmalloc_to_page().  But I don't know if ciphers should handle that
internally, blkcipher.c certainly seems to have several modes, although I
do not see how to *set* them.

Second problem is most likely what you were looking at. It is quite easy to
make the crypto code die.

For example, if I use "ccm(aes)" which can take the dst buffer, plus a hmac
buffer;

  cipher = kmalloc( ciphersize, ...
  hmac = kmalloc( 16, ...
  sg_set_buf( &sg[0], cipher, ciphersize);
  sg_set_buf( &sg[1], hmac, 16);
  aead_encrypt()...

and all is well, but if you shift hmac address away from PAGE boundary, like:

  hmac = kmalloc( 16 + 32, ...
  hmac += 32;
  sg_set_buf( &sg[1], hmac, 16);

ie, allocate a larger buffer, and put the pointer into the page a bit. And
it will die in scatterwalk very often. +32 isnt magical, any non-zero
number works.

Lund



-- 
Jorgen Lundman       | [off-list ref]
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help