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

>> 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)

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)

> 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)

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)

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)

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)

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:

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

On Wed, Jun 22, 2016 at 04:45:46PM -0700, Andy Lutomirski wrote: > > *However*, the other offender I've found (net/rxrpc/rxkad.c) uses > "pcbc(fcrypt)", which doesn't appear to be usable with this API. Is > there no way to say "I want synchronous crypto on this VA range" using > the skcipher API?

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

On Wed, Jun 22, 2016 at 02:48:24PM -0700, Andy Lutomirski wrote: > > Before I do this, can you explain what the difference is between > crypto_cipher and crypto_skcipher? net/bluetooth/smp.c currently uses > crypto_alloc_skcipher, which you added in: crypto_cipher operates on a single block.

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

On Wed, Jun 22, 2016 at 2:48 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote: >> On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu >> wrote: >>> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy

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

On Tue, Jun 21, 2016 at 5:52 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu > wrote: >> On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: >>> >>> Is there a straightforward way that bluetooth and,

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

On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: > > Is there a straightforward way that bluetooth and, potentially, other > drivers can just do synchronous crypto in a small buffer specified by > its virtual address? The actual cryptography part of the crypto code > already works

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

On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu wrote: > On Tue, Jun 21, 2016 at 10:43:40AM -0700, Andy Lutomirski wrote: >> >> Is there a straightforward way that bluetooth and, potentially, other >> drivers can just do synchronous crypto in a small buffer specified by

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

net/bluetooth/smp.c (in smp_e) wants to do AES-ECB on a 16-byte stack buffer, which seems eminently reasonable to me. It does it like this: sg_init_one(, data, 16); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL);