[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUnzasc+c5Dxmw+g6U07dTNU4RF0ug1bHj8j2en+7Xj1A@mail.gmail.com>
Date: Tue, 21 Jun 2016 17:52:23 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Andy Lutomirski <luto@...nel.org>, linux-bluetooth@...r.kernel.org,
Johan Hedberg <johan.hedberg@...il.com>,
Gustavo Padovan <gustavo@...ovan.org>,
Marcel Holtmann <marcel@...tmann.org>,
linux-crypto@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Doing crypto in small stack buffers (bluetooth vs vmalloc-stack
crash, etc)
On Tue, Jun 21, 2016 at 5:42 PM, Herbert Xu <herbert@...dor.apana.org.au> 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
>> its virtual address? The actual cryptography part of the crypto code
>> already works this way, but I can't find an API for it.
>
> Yes, single block users should use crypto_cipher_encrypt_one, an
> example would be drivers/md/dm-crypt.c.
>
Aha! I expected something like that to exist, but I couldn't find it.
I'll change the two offenders I've found so far to use it.
--Andy
Powered by blists - more mailing lists