> -----Original Message----- > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf > Of Ard Biesheuvel > Sent: Thursday, September 26, 2019 4:53 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: Jason A. Donenfeld <Jason@xxxxxxxxx>; Linux Crypto Mailing List <linux- > crypto@xxxxxxxxxxxxxxx>; linux-arm-kernel <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; > Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; David Miller <davem@xxxxxxxxxxxxx>; Greg KH > <gregkh@xxxxxxxxxxxxxxxxxxx>; Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>; Samuel > Neves <sneves@xxxxxxxxx>; Dan Carpenter <dan.carpenter@xxxxxxxxxx>; Arnd Bergmann > <arnd@xxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; Andy Lutomirski <luto@xxxxxxxxxx>; > Will Deacon <will@xxxxxxxxxx>; Marc Zyngier <maz@xxxxxxxxxx>; Catalin Marinas > <catalin.marinas@xxxxxxx> > Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API > > On Thu, 26 Sep 2019 at 16:03, Pascal Van Leeuwen > <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > > > > > -----Original Message----- > > > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > > Sent: Thursday, September 26, 2019 3:16 PM > > > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > > > Cc: Jason A. Donenfeld <Jason@xxxxxxxxx>; Linux Crypto Mailing List <linux- > > > crypto@xxxxxxxxxxxxxxx>; linux-arm-kernel <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; > > > Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; David Miller <davem@xxxxxxxxxxxxx>; Greg > KH > > > <gregkh@xxxxxxxxxxxxxxxxxxx>; Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>; Samuel > > > Neves <sneves@xxxxxxxxx>; Dan Carpenter <dan.carpenter@xxxxxxxxxx>; Arnd Bergmann > > > <arnd@xxxxxxxx>; Eric Biggers <ebiggers@xxxxxxxxxx>; Andy Lutomirski > <luto@xxxxxxxxxx>; > > > Will Deacon <will@xxxxxxxxxx>; Marc Zyngier <maz@xxxxxxxxxx>; Catalin Marinas > > > <catalin.marinas@xxxxxxx> > > > Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API > > > > > > On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen > > > <pvanleeuwen@xxxxxxxxxxxxxx> 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. > I guess that keypair object is a Wireguard specific thing? In that case it may not make a difference performance wise. I just would not expect a new (pair of) transforms to be allocated just for a rekey, only when a new connection is made. Thinking about this some more: Allocating a transform is about more than just allocating the object, there may be all kinds of side-effects like fallback ciphers being allocated, specific HW initialization being done, etc. I just feel that if you only need to change the key, you should only change the key. As that's what the driver would be optimized for. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
