On Tue, 20 Nov 2018 at 07:02, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Nov 19, 2018 at 01:24:51PM +0800, Herbert Xu wrote: > > > > In response to Martin's patch-set which I merged last week, I think > > here is quick way out for the zinc interface. > > > > Going through the past zinc discussions it would appear that > > everybody is quite happy with the zinc interface per se. The > > most contentious areas are in fact the algorithm implementations > > under zinc, as well as the conversion of the crypto API algorithms > > over to using the zinc interface (e.g., you can no longer access > > specific implementations). > > > > My proposal is to merge the zinc interface as is, but to invert > > how we place the algorithm implementations. IOW the implementations > > should stay where they are now, with in the crypto API. However, > > we will provide direct access to them for zinc without going through > > the crypto API. IOW we'll just export the functions directly. > > > > Here is a proof of concept patch to do it for chacha20-generic. > > It basically replaces patch 3 in the October zinc patch series. > > Actually this patch also exports the arm/x86 chacha20 functions > > too so they are ready for use by zinc. > > > > If everyone is happy with this then we can immediately add the > > zinc interface and expose the existing crypto API algorithms > > through it. This would allow wireguard to be merged right away. > > > > In parallel, the discussions over replacing the implementations > > underneath can carry on without stalling the whole project. > > > > PS This patch is totally untested :) > > Here is an updated version demonstrating how we could access the > accelerated versions of chacha20. It also includes a final patch > to deposit the new zinc version of x86-64 chacha20 into > arch/x86/crypto where it can be used by both the crypto API as well > as zinc. > > The key differences between this and the last zinc patch series: > > 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? 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. 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. > 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
