Re: [Qemu-devel] Question about add AF_ALG backend for virtio-crypto

[Daniel P. Berrange]

On Tue, Jan 10, 2017 at 12:17:48PM +0000, Gonglei (Arei) wrote:
> >
> > > >
> > > > >
> > > > > >
> > > > > > On Mon, Jan 09, 2017 at 01:43:10PM +0000, Stefan Hajnoczi wrote:
> > > > > > > On Mon, Jan 09, 2017 at 03:04:55PM +0800, Longpeng (Mike) wrote:
> > > > > > > > I'm one of Gonglei's virtio-crypto project members, and we plan 
> > > > > > > > to
> > add a
> > > > > > AF_ALG
> > > > > > > > backend for virtio-crypto(there's only builtin-backend 
> > > > > > > > currently).
> > > > > > > >
> > > > > > > > I found that Catalin, Paolo and Stefan had discussed about this 
> > > > > > > > in
> > 2015
> > > > > > > > (http://www.spinics.net/lists/kvm/msg115457.html), but it seems
> > that
> > > > > > Catalin
> > > > > > > > didn't do it, so I'm confuse about wether it is need to add a 
> > > > > > > > AF_ALG
> > > > > > backend.
> > > > > > > >
> > > > > > > > Do you have any suggestion? Thanks :)
> > > > > > >
> > > > > > > I have no objections to an AF_ALG backend in QEMU.
> > > > > >
> > > > > > Rather than do another backend for virtio-crypto, IMHO, we should 
> > > > > > have
> > > > > > an AF_ALG impl of the crypto/ APIs. That way any potential 
> > > > > > performance
> > > > > > benefits will enhance our LUKS encryption code too.
> > > > > >
> > > > > According to the currently schemas of crypto/ APIs, we can't choose 
> > > > > the
> > > > > specific backend dynamically. This is a limitation for virtio-crypto
> > > > > device I think.
> > > >
> > > > Do we really need to be able to choose the backend explicitly. If the 
> > > > AF_ALG
> > > > backend is faster, why would you simply not use that automatically if 
> > > > it is
> > > > available.
> > >
> > > Can we realize the purpose based on the crypto/ APIs? IIUC the crypto
> > > subsystem chooses a backend during the building according to the specific
> > priority,
> > > nettle > gcrypt > cipher-builtin.
> > >
> > > If we add an AF_ALG implementation for crypto subsystem, shall we set it
> > > as the highest priority? If so, other backends won't be used since AF_ALG
> > > is always available. If not, how can we use AF_ALG backend for crypto/ 
> > > API?
> > >
> > > Please correct me if I'm missing something.
> > 
> > While AF_ALG has been available for a while, not all features have. For
> > example AEAD support was only added in kernel 4.1
> > 
> OK.
> 
> > So if we had AF_ALG in QEMU, we would have to have a stacked impl, where
> > we try AF_ALG and then fallback to the current code when QEMU runs on a
> > kernel lacking the feature needed.
> > 
> It makes sense though the implementation will be more complicate
> since the code should identify the different error codes are returned
> by AF_ALG APIs.
> 
> > We could potentially also have a global arg to switch backends e.g.
> > 
> >  -crypto-backend [afalg|builtin]
> > 
> So the backend here is not the cryptodev backend?

No, it would apply to the crypto/ APIs, so it affects all users of those
APIs not just cryptodev


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|