Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-29 Thread George Spelvin
>> Also not mentioned in the documentation is that some algorithms *do* >> have different implementations depending on key size. SHA-2 is the >> classic example. > What do you mean by that? SHA has no keying at all. In this case, the analagous property is hash size. Sorry, I thought that was

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-28 Thread Herbert Xu
On Tue, Jun 28, 2016 at 10:32:12AM -0400, George Spelvin wrote: > > - struct crypto_instance > - struct crypto_spawn > - struct crypto_blkcipher > - struct blkcipher_desc > - More on the context structures returned by crypto_tfm_ctx blkcipher is obsolete and will be removed soon. So if you are

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-28 Thread George Spelvin
> We have actually gained quite a bit of documentation recently. > Have you looked at Documentation/DocBook/crypto-API.tmpl? > > More is always welcome of course. It's improved since I last looked at it, but there are still many structures that aren't described: - struct crypto_instance -

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-28 Thread Herbert Xu
On Tue, Jun 28, 2016 at 09:23:01AM -0400, George Spelvin wrote: > > Wow, I should see how you do that. I couldn't get it below 3 > blocks of temporary, and the dst SG list only gives you > one and a half. I don't mean that I'm using no temporary buffers at all, just that the actual crypto only

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-28 Thread George Spelvin
Herbert Xu wrote: > I'm currently working on cts and I'm removing the stack usage > altogether by having it operate on the src/dst SG lists only. Wow, I should see how you do that. I couldn't get it below 3 blocks of temporary, and the dst SG list only gives you one and a half. > BTW, the only

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-28 Thread Herbert Xu
On Tue, Jun 28, 2016 at 08:37:43AM -0400, George Spelvin wrote: > Just a note, crypto/cts.c also does a lot of sg_set_buf() in stack buffers. > > I have a local patch (appended, if anyone wants) to reduce the wasteful > amount of buffer space it uses (from 7 to 3 blocks on encrypt, from > 6 to 3

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-28 Thread George Spelvin
Just a note, crypto/cts.c also does a lot of sg_set_buf() in stack buffers. I have a local patch (appended, if anyone wants) to reduce the wasteful amount of buffer space it uses (from 7 to 3 blocks on encrypt, from 6 to 3 blocks on decrypt), but it would take some rework to convert to

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-23 Thread Andy Lutomirski
On Wed, Jun 22, 2016 at 11:41 PM, Herbert Xu wrote: > On Thu, Jun 23, 2016 at 11:48:25AM +0800, Herbert Xu wrote: >> >> No we never had such an API in the kernel. However, I see that >> rxkad does some pretty silly things and we should be able to avoid >> using the

Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack crash, etc)

2016-06-23 Thread Herbert Xu
On Thu, Jun 23, 2016 at 11:48:25AM +0800, Herbert Xu wrote: > > No we never had such an API in the kernel. However, I see that > rxkad does some pretty silly things and we should be able to avoid > using the stack in pretty much all cases. Let me try to come up with > something. Here it is: