Re: Re: Re: [PATCH v3 0/6] Support akcipher for virtio-crypto

[zhenwei pi]

On 3/24/22 02:03, Eric Biggers wrote:
> On Wed, Mar 23, 2022 at 03:32:37PM +0800, zhenwei pi wrote:
> > On 3/23/22 13:17, Eric Biggers wrote:
> > > On Wed, Mar 23, 2022 at 10:49:06AM +0800, zhenwei pi wrote:
> > > > v2 -> v3:
> > > > - Introduce akcipher types to qapi
> > > > - Add test/benchmark suite for akcipher class
> > > > - Seperate 'virtio_crypto: Support virtio crypto asym operation' into:
> > > >     - crypto: Introduce akcipher crypto class
> > > >     - virtio-crypto: Introduce RSA algorithm
> > > >
> > > > v1 -> v2:
> > > > - Update virtio_crypto.h from v2 version of related kernel patch.
> > > >
> > > > v1:
> > > > - Support akcipher for virtio-crypto.
> > > > - Introduce akcipher class.
> > > > - Introduce ASN1 decoder into QEMU.
> > > > - Implement RSA backend by nettle/hogweed.
> > > >
> > > > Lei He (3):
> > > >     crypto-akcipher: Introduce akcipher types to qapi
> > > >     crypto: Implement RSA algorithm by hogweed
> > > >     tests/crypto: Add test suite for crypto akcipher
> > > >
> > > > Zhenwei Pi (3):
> > > >     virtio-crypto: header update
> > > >     crypto: Introduce akcipher crypto class
> > > >     virtio-crypto: Introduce RSA algorithm
> > >
> > > You forgot to describe the point of this patchset and what its use case is.
> > > Like any other Linux kernel patchset, that needs to be in the cover letter.
> > >
> > > - Eric
> > Thanks Eric for pointing this missing part.
> >
> > This feature provides akcipher service offloading capability. QEMU side
> > handles asymmetric requests via virtio-crypto devices from guest side, do
> > encrypt/decrypt/sign/verify operations on host side, and return the result
> > to guest.
> >
> > This patchset implements a RSA backend by hogweed from nettle, it works
> > together with guest patch:
> > https://lkml.org/lkml/2022/3/1/1425
>
> So what is the use case?
>
> - Eric
Hi,

In our plan, the feature is designed for HTTPS offloading case and other 
applications which use kernel RSA/ecdsa by keyctl syscall. The full 
picture shows bellow:


                  Nginx/openssl[1] ... Apps
Guest   -----------------------------------------
                   virtio-crypto driver[2]
-------------------------------------------------
                   virtio-crypto backend[3]
Host    -----------------------------------------
                  /          |          \
              builtin[4]   vhost     keyctl[5] ...


[1] User applications can offload RSA calculation to kernel by keyctl 
syscall. There is no keyctl engine in openssl currently, we developed a 
engine and tried to contribute it to openssl upstream, but openssl 1.x 
does not accept new feature. Link:
        https://github.com/openssl/openssl/pull/16689

This branch is available and maintained by Lei <helei.sig11@bytedance.com>
        https://github.com/TousakaRin/openssl/tree/OpenSSL_1_1_1-kctl_engine

We tested nginx(change config file only) with openssl keyctl engine, it 
works fine.

[2] virtio-crypto driver is used to communicate with host side, send 
requests to host side to do asymmetric calculation.
        https://lkml.org/lkml/2022/3/1/1425

[3] virtio-crypto backend handles requests from guest side, and forwards 
request to crypto backend driver of QEMU.

[4] Currently RSA is supported only in builtin driver. This driver is 
supposed to test the full feature without other software(Ex vhost 
process) and hardware dependence. ecdsa is introduced into qapi type 
without implementation, this may be implemented in Q3-2022 or later. If 
ecdsa type definition should be added with the implementation together, 
I'll remove this in next version.

[5] keyctl backend is in development, we will post this feature in 
Q2-2022. keyctl backend can use hardware acceleration(Ex, Intel QAT).

Setup the full environment, tested with Intel QAT on host side, the QPS 
of HTTPS increase to ~200% in a guest.

VS PCI passthrough: the most important benefit of this solution makes 
the VM migratable.

--
zhenwei pi