-----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
[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 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 ...

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