From: Jorgen Lundman <lundman@lundman.net>
To: linux-crypto@vger.kernel.org
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Subject: Re: Crypto causes panic in scatterwalk_done with large/multiple buffers
Date: Sun, 18 Nov 2012 09:29:05 +0900 [thread overview]
Message-ID: <50A82BD1.4000505@lundman.net> (raw)
In-Reply-To: <20121117103901.664145ijlv5r29wk@www.dalek.fi>
>
> 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 | <lundman@lundman.net>
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)
next prev parent reply other threads:[~2012-11-18 0:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-15 9:03 Crypto causes panic in scatterwalk_done with large/multiple buffers Jorgen Lundman
2012-11-17 0:42 ` Jussi Kivilinna
2012-11-17 8:39 ` Jussi Kivilinna
2012-11-18 0:29 ` Jorgen Lundman [this message]
2012-11-18 2:10 ` Jorgen Lundman
2012-11-18 17:40 ` Jussi Kivilinna
2012-11-19 0:29 ` Jorgen Lundman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50A82BD1.4000505@lundman.net \
--to=lundman@lundman.net \
--cc=jussi.kivilinna@mbnet.fi \
--cc=linux-crypto@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox