Hi Gonglei, Please find my comments inline. Regards Varun
> -----Original Message----- > From: Gonglei (Arei) [mailto:arei.gong...@huawei.com] > Sent: Wednesday, November 25, 2015 1:14 PM > To: Sethi Varun-B16395 <varun.se...@freescale.com>; virtio-dev@lists.oasis- > open.org; qemu-devel@nongnu.org > Cc: Hanweidong (Randy) <hanweid...@huawei.com>; m...@redhat.com; > Claudio Fontana <claudio.font...@huawei.com>; Huangpeng (Peter) > <peter.huangp...@huawei.com>; Lauri Leukkunen > <lauri.leukku...@huawei.com>; Jani Kokkonen > <jani.kokko...@huawei.com>; Crasta Denis-B22176 > <denis.cra...@freescale.com>; Pathak Arun-B33046 > <arun.pat...@freescale.com> > Subject: RE: [RFC v1] virtio-crypto specification > > Hello Varun, > > > > -----Original Message----- > > From: Varun Sethi [mailto:varun.se...@freescale.com] > > Sent: Wednesday, November 25, 2015 3:08 AM > > Subject: RE: [RFC v1] virtio-crypto specification > > > > Hi Gonglei, > > We have been working on the virtio-ipsec look-aside accelerator > > device specification at the OPNFV DPACC forum. The virtio-ipsec device > > is aimed at providing the protocol offload capabilities (offered by > > security hardware > > accelerator) to the VM. The device supports a control queue and > > encap/decap queue pair per guest vcpu (multi queue support). Based on > > the feature bits, a notification queue can also be supported. > > Following document gives the details for the virtio-ipsec device: > > https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelerator-rev- > 3. > > docx > > > > Currently we are focusing on userspace virtio-ipsec backend emulation. > > We are working on a POC for vhost-user IPSec backend emulation and > > guest VM kernel virtio-ipsec driver. > > > > Following document provides guest API details to utilize the > > virtio-ipsec look aside accelerator. > > https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelerato > > r-gapi-r > > ev02.pdf > > > > Actually, our virtio-crypto device isn't limited on NFV scenario, but all > encrypt & > decrypt scenarios which need to use para-virtualization of accelerator > hardwares. > [Varun] Agreed, but we can work towards a generic specification. > > We can look at collaborating for the virtio-crypto device definition. > > > > Welcome to join us :) > [Varun] Thanks, it would be nice if we can leverage the work done as a part of the virtio-ipsec device specification. I have also added Lingli to the mail chain. Lingli is leading the OPNFV DPACC effort. Please let us know if we can have a discussion on this. > Regards, > -Gonglei > > > Regards > > Varun > > > > -----Original Message----- > > From: qemu-devel-bounces+varun.sethi=freescale....@nongnu.org > > [mailto:qemu-devel-bounces+varun.sethi=freescale....@nongnu.org] On > > Behalf Of Gonglei (Arei) > > Sent: Friday, November 20, 2015 8:58 AM > > To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org > > Cc: Hanweidong (Randy) <hanweid...@huawei.com>; m...@redhat.com; > > Claudio Fontana <claudio.font...@huawei.com>; Huangpeng (Peter) > > <peter.huangp...@huawei.com>; Lauri Leukkunen > > <lauri.leukku...@huawei.com>; Gonglei (Arei) > > <arei.gong...@huawei.com>; Jani Kokkonen <jani.kokko...@huawei.com> > > Subject: [Qemu-devel] [RFC v1] virtio-crypto specification > > > > Hi guys, > > > > After initial discussion at this year's KVM forum, I post the RFC > > version of virtio-crypto device specification now. > > > > If you have any comments, please let me know, thanks. > > > > Regards, > > -Gonglei > > > > > > 1 Crypto Device > > > > The virtio crypto device is a virtual crypto device (ie. hardware > > crypto accelerator card). Encrypt and decrypt requests are placed in > > the data queue, and handled by the real hardware crypto accelerators > > finally. A second queue is the controlling queue, which is used to > > create/destroy session or some other advanced filtering features. > > > > 1.1 Device ID > > > > 65535 (experimental) > > > > 1.2 Virtqueues > > > > 0 > > controlq > > 1 > > dataq > > > > 1.3 Feature bits > > > > VIRTIO_CRYPTO_F_REQ_SIZE_MAX (0) > > Maximum size of any single request is in “size_max”. > > VIRTIO_CRYPTO_F_SYM (1) > > Device supports the symmetric cryptography API. > > VIRTIO_CRYPTO_F_DH (2) > > Device supports the Diffie Hellman API. > > VIRTIO_CRYPTO_F_DSA (3) > > Device supports the DSA API. > > VIRTIO_CRYPTO_F_RSA (4) > > Device supports the RSA API. > > VIRTIO_CRYPTO_F_EC (5) > > Device supports the Elliptic Curve API. > > VIRTIO_CRYPTO_F_ECDH (6) > > Device supports the Elliptic Curve Diffie Hellman API. > > VIRTIO_CRYPTO_F_ECDSA (7) > > Device supports the Elliptic Curve DSA API. > > VIRTIO_CRYPTO_F _KEY (8) > > Device supports the Key Generation API. > > VIRTIO_CRYPTO_F_LN (9) > > Device supports the Large Number API. > > VIRTIO_CRYPTO_F_PRIME (10) > > Device supports the prime number testing API. > > VIRTIO_CRYPTO_F_DRGB (11) > > Device supports the DRGB API. > > VIRTIO_CRYPTO_F_NRGB (12) > > Device supports the NRGB API. > > VIRTIO_CRYPTO_F_RAND (13) > > Device supports the random bit/number generation API. > > > > 1.4 Device configuration layout > > > > struct virtio_crypto_config { > > le32 size_max; /* Maximum size of any single request */ } > > > > 1.5 Device Initialization > > > > 1. The initialization routine should identify the data and control > > virtqueues. > > 2. If the VIRTIO_CRYPTO_F_SYM feature bit is negotiated, identify the > > device supports the symmetric cryptography API, which as the same as > > other features. > > > > 1.6 Device Operation > > > > The controlq is used to control session operations, such as create or > > destroy. > > Meanwhile, some other features or functions can also be handled by controlq. > > The control request is preceded by a header: > > struct virtio_crypto_ctx_outhdr { > > /* cipher algorithm type (ie. aes-cbc ) */ > > __virtio32 alg; > > /* length of key */ > > __virtio32 keylen; > > /* reserved */ > > __virtio32 flags; > > /* control type */ > > uint8_t type; > > /* encrypt or decrypt */ > > uint8_t op; > > /* mode of hash operation, including authenticated/plain/nested hash */ > > uint8_t hash_mode; > > /* authenticate hash/cipher ordering */ > > uint8_t alg_chain_order; > > /* length of authenticated key */ > > __virtio32 auth_key_len; > > /* hash algorithm type */ > > __virtio32 hash_alg; > > }; > > The encrypt/decrypt requests and the corresponding results are > > transmitted by placing them in dataq. The request itself is preceded by a > header: > > struct virtio_crypto_req_outhdr { > > /* algorithm type (ie. aes-128-cbc ) */ > > __virtio32 mode; > > /* length of iv */ > > __virtio32 ivlen; > > /* length of source data */ > > __virtio32 len; > > /* length of auth data */ > > __virtio32 auth_len; > > /* the backend session id */ > > __virtio64 session_id; > > /* reserved */ > > __virtio32 flags; > > }; > > > > Both ctx and data requests end by a status byte. The final status byte > > is written by the device: either VIRTIO_CRYPTO_S_OK for success, > > VIRTIO_BLK_S_IOERR for device or driver error or VIRTIO_BLK_S_UNSUPP > > for a request unsupported by device, VIRTIO_CRYPTO_S_BADMSG for > > verification failed when decrypt AEAD algorithms: > > > > #define VIRTIO_CRYPTO_S_OK 0 > > #define VIRTIO_CRYPTO_S_ERR 1 > > #define VIRTIO_CRYPTO_S_UNSUPP 2 > > #define VIRTIO_CRYPTO_S_BADMSG 3 > > > > For symmetric cryptography, three types algorithms are supported: > > enum { > > VIRTIO_CRYPTO_ABLKCIPHER, > > VIRTIO_CRYPTO_AEAD, > > VIRTIO_CRYPTO_HASH, > > }; > > VIRTIO_CRYPTO_ABLKCIPHER: Asynchronous Block Cipher. > > VIRTIO_CRYPTO_AEAD: Authenticated Encryption With Associated Data > > (AEAD) Cipher. > > VIRTIO_CRYPTO_HASH: Hash and MAC (Message Authentication Code) cipher. > > > > 1.6.1 Encryption Operation > > > > Bothe ctrlq and dataq virtqueue are bidirectional. > > Step1: Create a session: > > 1. The front-end driver fill out the context message, include algorithm > name, > > key, keylen etc; > > 2. The front-end driver send a context message to the backend device by > > controlq; > > 3. The backend driver create a session using the message transmitted by > > controlq; > > 4. Return a session id to the driver. > > Step 2: Execute the detail encryption operation: > > 1. The front-end driver fill out the encrypt requests; > > 2. Put the requests into dataq and kick the virtqueue; > > 3. The backend driver execute the encryption operation according the > > requests’ arguments; > > 4. Return the encryption result to the front-end driver by dataq. > > 5. The front-end driver callback handle the result and over > > > > Note: the front-end driver needs to support both synchronous and > > asynchronous encryption. Even then the performance is poor in > > synchronous operation because frequent context switching and virtualization > overhead. > > > > 1.6.2 Decryption Operation > > > > The decryption process is the same with encryption, except that AEAD > > algorithm needs to be verified before decryption, if the verify result > > is not correct, the device will directly return VIRTIO_CRYPTO_S_BADMSG > > (bad > > message) to front-end driver. > >
