From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Pf6-0001Xg-QK for qemu-devel@nongnu.org; Thu, 03 Dec 2015 03:54:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4Pf3-00029X-Dy for qemu-devel@nongnu.org; Thu, 03 Dec 2015 03:54:48 -0500 Received: from cmccmta3.chinamobile.com ([221.176.66.81]:8808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4Pf0-00028G-UK for qemu-devel@nongnu.org; Thu, 03 Dec 2015 03:54:45 -0500 From: "Lingli Deng" References: <33183CC9F5247A488A2544077AF19020B0288911@SZXEMA503-MBS.china.huawei.com> <33183CC9F5247A488A2544077AF19020B02A35DE@SZXEMA503-MBS.china.huawei.com> <0ac601d127f2$72851bf0$578f53d0$@com> In-Reply-To: Date: Thu, 3 Dec 2015 16:55:34 +0800 Message-ID: <043d01d12da8$5f70f910$1e52eb30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: zh-cn Subject: [Qemu-devel] =?utf-8?b?562U5aSNOiBbUkZDIHYxXSB2aXJ0aW8tY3J5cHRv?= =?utf-8?q?_specification?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Denis Crasta' , 'Varun Sethi' , "'Gonglei (Arei)'" , virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org Cc: 'Caraman Mike' , mst@redhat.com, "'Hanweidong (Randy)'" , 'Claudio Fontana' , "'Huangpeng (Peter)'" , 'Lauri Leukkunen' , 'Arun Pathak' , 'Silbermintz Michal' , 'Jani Kokkonen' , 'Grigore Sebastian' , 'Rajesh Kumar Madabushi' Hi guys, I am curious about the status of this proposal at OASIS.=20 When is it planned for release? Is there any running PoC for the = proposal? Is it still open? Any plan for upstreamming? Thanks, Lingli -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Denis Crasta = [mailto:denis.crasta@freescale.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2015=E5=B9=B411=E6=9C=8826=E6=97=A5 10:44 =E6=94=B6=E4=BB=B6=E4=BA=BA: Lingli Deng; Varun Sethi; 'Gonglei (Arei)'; = virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org =E6=8A=84=E9=80=81: 'Hanweidong (Randy)'; mst@redhat.com; 'Claudio = Fontana'; 'Huangpeng (Peter)'; 'Lauri Leukkunen'; 'Jani Kokkonen'; Arun = Pathak; Caraman Mike; Rajesh Kumar Madabushi; Silbermintz Michal; = Grigore Sebastian =E4=B8=BB=E9=A2=98: RE: [RFC v1] virtio-crypto specification +Rajesh, Michal, Sebastian Denis -----Original Message----- From: Lingli Deng [mailto:denglingli@chinamobile.com] Sent: Wednesday, November 25, 2015 6:31 PM To: Sethi Varun-B16395 ; 'Gonglei (Arei)' = ; virtio-dev@lists.oasis-open.org; = qemu-devel@nongnu.org Cc: 'Hanweidong (Randy)' ; mst@redhat.com; = 'Claudio Fontana' ; 'Huangpeng (Peter)' = ; 'Lauri Leukkunen' = ; 'Jani Kokkonen' = ; Crasta Denis-B22176 = ; Pathak Arun-B33046 = ; Caraman Mihai Claudiu-B02008 = Subject: =E7=AD=94=E5=A4=8D: [RFC v1] virtio-crypto specification Hi Varun, Thanks for the bridging.=20 Hi Gonglei and virtio-crypto guys,=20 As Varun said, dpacc is working on enabling the portability of data = plane VNFs (leveraging software/hardware accelerators in the host) = across hardware platforms, and virtio extensions for such accelerator = had been recognized as a promising solution. In particular, we are = interested in the use-case of a smallcell GW VNF, where hardware/host = accelerators are used for crypto offloading. As part of the OPNFV = initiative, we are targeting at adding features to the open-source = platform, which would used as a reference implementation for NFV = deployment. However, we are not member of OASIS, and is not familiar with its = organization or procedure. So we start with the gap analysis and the PoC = implementation, without knowing that there is actually an OASIS thread = taking place in parallel. I understand it may not the the only application scenario for = virtio-crypto spec you are doing, but assume it could be an interesting = one in operators' NFV deployment. I believe we should definitely encourage this discussion and try to work = together.=20 I suppose we can start with an exchange of what we expect in our usecase = and PoC with what you would provide with the specified virtual device. Please advise how we can start collaboration. Regards, Lingli +86 13810597148 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Varun Sethi = [mailto:Varun.Sethi@freescale.com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2015=E5=B9=B411=E6=9C=8825=E6=97=A5 20:41 =E6=94=B6=E4=BB=B6=E4=BA=BA: Gonglei (Arei); = virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org =E6=8A=84=E9=80=81: Hanweidong (Randy); mst@redhat.com; Claudio Fontana; = Huangpeng (Peter); Lauri Leukkunen; Jani Kokkonen; Denis Crasta; Arun = Pathak; Lingli Deng; Caraman Mike =E4=B8=BB=E9=A2=98: RE: [RFC v1] virtio-crypto specification Hi Gonglei, Please find my comments inline. Regards Varun > -----Original Message----- > From: Gonglei (Arei) [mailto:arei.gonglei@huawei.com] > Sent: Wednesday, November 25, 2015 1:14 PM > To: Sethi Varun-B16395 ; > virtio-dev@lists.oasis- open.org; qemu-devel@nongnu.org > Cc: Hanweidong (Randy) ; mst@redhat.com;=20 > Claudio Fontana ; Huangpeng (Peter)=20 > ; Lauri Leukkunen=20 > ; Jani Kokkonen=20 > ; Crasta Denis-B22176=20 > ; Pathak Arun-B33046=20 > > Subject: RE: [RFC v1] virtio-crypto specification >=20 > Hello Varun, >=20 >=20 > > -----Original Message----- > > From: Varun Sethi [mailto:Varun.Sethi@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=20 > > device specification at the OPNFV DPACC forum. The virtio-ipsec=20 > > device is aimed at providing the protocol offload capabilities=20 > > (offered by security hardware > > accelerator) to the VM. The device supports a control queue and=20 > > encap/decap queue pair per guest vcpu (multi queue support). Based=20 > > 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-accelera > > tor-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=20 > > guest VM kernel virtio-ipsec driver. > > > > Following document provides guest API details to utilize the=20 > > virtio-ipsec look aside accelerator. > > https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelera > > to > > r-gapi-r > > ev02.pdf > > >=20 > Actually, our virtio-crypto device isn't limited on NFV scenario, but=20 > all encrypt & decrypt scenarios which need to use para-virtualization=20 > of accelerator hardwares. >=20 [Varun] Agreed, but we can work towards a generic specification. > > We can look at collaborating for the virtio-crypto device = definition. > > >=20 > Welcome to join us :) >=20 [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 >=20 > > Regards > > Varun > > > > -----Original Message----- > > From: qemu-devel-bounces+varun.sethi=3Dfreescale.com@nongnu.org > > [mailto:qemu-devel-bounces+varun.sethi=3Dfreescale.com@nongnu.org] = On=20 > > Behalf Of Gonglei (Arei) > > Sent: Friday, November 20, 2015 8:58 AM > > To: virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org > > Cc: Hanweidong (Randy) ; mst@redhat.com;=20 > > Claudio Fontana ; Huangpeng (Peter)=20 > > ; Lauri Leukkunen=20 > > ; Gonglei (Arei)=20 > > ; Jani Kokkonen > > Subject: [Qemu-devel] [RFC v1] virtio-crypto specification > > > > Hi guys, > > > > After initial discussion at this year's KVM forum, I post the RFC=20 > > 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=20 > > 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=20 > > 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 =E2=80=9Csize_max=E2=80=9D. > > 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=20 > > the device supports the symmetric cryptography API, which as the=20 > > 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=20 > > 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 =EF=AC=81nal = status=20 > > byte is written by the device: either VIRTIO_CRYPTO_S_OK for=20 > > success, VIRTIO_BLK_S_IOERR for device or driver error or=20 > > VIRTIO_BLK_S_UNSUPP for a request unsupported by device,=20 > > 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=E2=80=99 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=20 > > asynchronous encryption. Even then the performance is poor in=20 > > synchronous operation because frequent context switching and=20 > > 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=20 > > result is not correct, the device will directly return=20 > > VIRTIO_CRYPTO_S_BADMSG (bad > > message) to front-end driver. > >