Hi Ard: On Tue, Nov 20, 2018 at 11:32:05AM +0100, Ard Biesheuvel wrote: > > > 1. The crypto API algorithms remain individually accessible, this > > is crucial as these algorithm names are exported to user-space so > > changing the names to foo-zinc is not going to work. > > Are you saying user space may use names like "ctr-aes-neon" directly > rather than "ctr(aes)" for any implementation of the mode? Yes. In fact it's used for FIPS certification testing. > If so, that is highly unfortunate, since it means we'd be breaking > user space by wrapping a crypto library function with its own arch > specific specializations into a generic crypto API wrapper. You can never break things by introducing new algorithms. The problem is only when you remove existing ones. > Note that I think that using AF_ALG to access software crypto routines > (as opposed to accelerators) is rather pointless to begin with, but if > it permits that today than we're stuck with it. Sure, nobody sane should be doing it. But when it comes to government certification... :) > > 2. The arch-specific algorithm code lives in their own module rather > > than in a monolithic module. > > This is one of the remaining issues I have with Zinc. However, modulo > the above concerns, I think it does make sense to have a separate > function API for synchronous software routines below the current > crypto API. What I don't want is a separate Zinc kingdom with a > different name, different maintainers and going through a different > tree, and with its own approach to test vectors, arch specific code, > etc etc Even without the issue of replacing chacha20-generic with chacha20-zinc which breaks point 1 above, we simply don't want or need to go through zinc's run-time implementation choice for the crypto API algorithms. They've already paid for the indirect function call so why make them go through yet another run-time branch? If the optics of having the code in crypto is the issue, we could move the actual algorithm code into a third location, perhaps arch/x86/crypto/lib or arch/x86/lib/crypto. Then both zinc and the crypto API can sit on top of that. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
