On Tue, Oct 11, 2022 at 05:03:31PM +0800, Herbert Xu wrote: > On Mon, Oct 10, 2022 at 09:15:48AM -0600, Jason A. Donenfeld wrote: > > > > Do you mean to say that other drivers that use hardware-backed keys do > > so by setting "cra_name" to something particular? Like instead of "aes" > > it'd be "aes-but-special-for-this-driver"? If so, that would seem to > > break the design of the crypto API. Which driver did you see that does > > this? Or perhaps, more generally, what are the drivers that Herbert is > > talking about when he mentions the "plenty of existing drivers" that > > already do this? > > Grep for paes for the existing drivers that support this. I don't > have anything against this feature per se, but the last thing we > want is a proliferation of different ways of doing the same thing. I've got no stake in this, but isn't the whole idea that if you specify "aes" you get AES, and if you specify "cbc(aes)" you get AES-CBC, and so forth? And so leaking implementation details into the algorithm name feels like it breaks the abstraction a bit. Rather, drivers that do AES should be called "aes". For this hardware key situation, I guess that means keys have a type (in-memory vs hardware-resident). Then, a crypto operation takes an "algorithm" and a "key", and the abstraction then picks the best implementation that's compatible with both the "algorithm" and the "key". I haven't looked carefully, but I assume that's more or less what this patchset does. If you don't want a proliferation of different ways of doing the same thing, maybe the requirement should be that the author of this series also converts the existing "paes" kludge to use the new thing he's proposing? Or maybe the "paes" kludge is better for other reasons? I don't know really. Just my 2¢, but feel free to disregard, as I really have nothing to do with this change. Jason
