On Thu, 26 Sep 2019 at 16:03, Pascal Van Leeuwen <pvanleeu...@verimatrix.com> wrote: > > > -----Original Message----- > > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > > Sent: Thursday, September 26, 2019 3:16 PM > > To: Pascal Van Leeuwen <pvanleeu...@verimatrix.com> > > Cc: Jason A. Donenfeld <ja...@zx2c4.com>; Linux Crypto Mailing List <linux- > > cry...@vger.kernel.org>; linux-arm-kernel > > <linux-arm-ker...@lists.infradead.org>; > > Herbert Xu <herb...@gondor.apana.org.au>; David Miller > > <da...@davemloft.net>; Greg KH > > <gre...@linuxfoundation.org>; Linus Torvalds > > <torva...@linux-foundation.org>; Samuel > > Neves <sne...@dei.uc.pt>; Dan Carpenter <dan.carpen...@oracle.com>; Arnd > > Bergmann > > <a...@arndb.de>; Eric Biggers <ebigg...@google.com>; Andy Lutomirski > > <l...@kernel.org>; > > Will Deacon <w...@kernel.org>; Marc Zyngier <m...@kernel.org>; Catalin > > Marinas > > <catalin.mari...@arm.com> > > Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto > > API > > > > On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen > > <pvanleeu...@verimatrix.com> wrote: > > ... > > > > > > > > My preference would be to address this by permitting per-request keys > > > > in the AEAD layer. That way, we can instantiate the transform only > > > > once, and just invoke it with the appropriate key on the hot path (and > > > > avoid any per-keypair allocations) > > > > > > > This part I do not really understand. Why would you need to allocate a > > > new transform if you change the key? Why can't you just call setkey() > > > on the already allocated transform? > > > > > > > Because the single transform will be shared between all users running > > on different CPUs etc, and so the key should not be part of the TFM > > state but of the request state. > > > So you need a transform per user, such that each user can have his own > key. But you shouldn't need to reallocate it when the user changes his > key. I also don't see how the "different CPUs" is relevant here? I can > share a single key across multiple CPUs here just fine ... >
We need two transforms per connection, one for each direction. That is how I currently implemented it, and it seems to me that, if allocating/freeing those on the same path as where the keypair object itself is allocated is too costly, I wonder why allocating the keypair object itself is fine. But what I am suggesting is to use a single TFM which gets shared by all the connections, where the key for each operation is provided per-request. That TFM cannot have a key set, because each user may use a different key.
