On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > I realize you've put a lot of good and hard work into the existing > I am also concerned about your claim that all software algorithms will > be moved into this crypto library. You are not specific about whose > responsibility it will be that this is going to happen in a timely > fashion. But more importantly, it is not clear at all how you expect > this to work for, e.g., h/w instruction based SHAxxx or AES in various > chaining modes, which should be used only on cores that implement > those instructions (note that on arm64, we have optional instructions > for AES, PMULL, SHA1, SHA256, SHA512, SHA3, SM3 and SM4). Are all > those implementations (only few of which will be used on a certain > core) going to be part of the monolithic library? What are the APIs > going to look like for block ciphers, taking chaining modes into > account? I'm not convinced that there's any real need for *all* crypto algorithms to move into lib/zinc or to move at all. As I see it, there are two classes of crypto algorithms in the kernel: a) Crypto that is used by code that chooses its algorithm statically and wants synchronous operations. These include everything in drivers/char/random.c, but also a bunch of various networking things that are hardcoded and basically everything that uses stack buffers. (This means it includes all the code that I broke when I did VMAP_STACK. Sign.) b) Crypto that is used dynamically. This includes dm-crypt (aes-xts-plain64, aes-cbc-essiv, etc), all the ALG_IF interfaces, a lot of IPSEC stuff, possibly KCM, and probably many more. These will get comparatively little benefit from being converted to a zinc-like interface. For some of these cases, it wouldn't make any sense at all to convert them. Certainly the ones that do async hardware crypto using DMA engines will never look at all like zinc, even under the hood. I think that, as a short-term goal, it makes a lot of sense to have implementations of the crypto that *new* kernel code (like Wireguard) wants to use in style (a) that live in /lib, and it obviously makes sense to consolidate their implementations with the crypto/ implementations in a timely manner. As a medium-term goal, adding more algorithms as needed for things that could use the simpler APIs (Bluetooth, perhaps) would make sense. But I see no reason at all that /lib should ever contain a grab-bag of crypto implementations just for the heck of it. They should have real in-kernel users IMO. And this means that there will probably always be some crypto implementations in crypto/ for things like aes-xts. --Andy
