On 11/17/2016 12:01 PM, Michael Weiser wrote: > Hi Horia, > > On Thu, Nov 17, 2016 at 10:18:50AM +0200, Horia Geant?? wrote: > >> ablkcipher API is not completely removed from kernels <= v4.9. >> Thus it's still valid to use ablkcipher algorithms. > > I was under the impression that skcipher is just a unified API meant to > give a common way of accessing synchronous and asynchronous block > ciphers. That's why I assumed it to be a drop-in replacement in our > case. > Yes, the intent is to replace (a)blkcipher with skcipher, however the conversion is not over yet.
> This commit spells it out clearly IMO: > https://github.com/torvalds/linux/commit/ba871e1d299154953dcee23590c0316283897261 > I think the documentation update was either too early or targeted towards discouraging the proliferation of ablkcipher. > Can you point me to an implementor that somehow registers an > ansynchronous block cipher that's not accessible via skcipher? > caam driver is what triggered this patch: https://github.com/torvalds/linux/blob/master/drivers/crypto/caam/caamalg.c#L2922 On the linux-crypto mailing list you can see there is on-going work: crypto: skcipher - skcipher algorithm conversion part 3 https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21642.html and a part 4 (converting existing drivers) will surely follow. >> Fix the case when implementers register ablkcipher algorithms >> and cryptodev casts them to skcipher without checking their type. > > So is your patch meant as a stop-gap measure for releases ablk/skcipher > hybrid kernels until all implementors have made their ciphers available > via skcipher as well or did I get it wrong and (part of) the ablkcipher > API will stick around indefinitely? > First option - "hybrid" kernels. Horia _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
