-----Original Message-----
From: linux-crypto-owner@vger.kernel.org <redacted> On Behalf
Of Ard Biesheuvel
Sent: Thursday, September 26, 2019 4:53 PM
To: Pascal Van Leeuwen <redacted>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>; Linux Crypto Mailing List <linux-
crypto@vger.kernel.org>; linux-arm-kernel [off-list ref];
Herbert Xu [off-list ref]; David Miller [off-list ref]; Greg KH
[off-list ref]; Linus Torvalds [off-list ref]; Samuel
Neves [off-list ref]; Dan Carpenter [off-list ref]; Arnd Bergmann
[off-list ref]; Eric Biggers [off-list ref]; Andy Lutomirski [off-list ref];
Will Deacon [off-list ref]; Marc Zyngier [off-list ref]; Catalin Marinas
[off-list ref]
Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API

On Thu, 26 Sep 2019 at 16:03, Pascal Van Leeuwen
[off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: Ard Biesheuvel <redacted>
Sent: Thursday, September 26, 2019 3:16 PM
To: Pascal Van Leeuwen <redacted>
Cc: Jason A. Donenfeld <Jason@zx2c4.com>; Linux Crypto Mailing List <linux-
crypto@vger.kernel.org>; linux-arm-kernel [off-list ref];
Herbert Xu [off-list ref]; David Miller [off-list ref]; Greg

KH

quoted

quoted

[off-list ref]; Linus Torvalds [off-list ref]; Samuel
Neves [off-list ref]; Dan Carpenter [off-list ref]; Arnd Bergmann
[off-list ref]; Eric Biggers [off-list ref]; Andy Lutomirski

[off-list ref];

quoted

quoted

Will Deacon [off-list ref]; Marc Zyngier [off-list ref]; Catalin Marinas
[off-list ref]
Subject: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API

On Thu, 26 Sep 2019 at 15:06, Pascal Van Leeuwen
[off-list ref] wrote:
...

quoted

quoted

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel