[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v1] virtio-crypto specification
From: |
Denis Crasta |
Subject: |
Re: [Qemu-devel] [RFC v1] virtio-crypto specification |
Date: |
Wed, 25 Nov 2015 14:25:07 +0000 |
+Michal and Sebastian.
Denis
-----Original Message-----
From: Sethi Varun-B16395
Sent: Wednesday, November 25, 2015 4:41 AM
To: Gonglei (Arei) <address@hidden>; address@hidden; address@hidden
Cc: Hanweidong (Randy) <address@hidden>; address@hidden; Claudio Fontana
<address@hidden>; Huangpeng (Peter) <address@hidden>; Lauri Leukkunen
<address@hidden>; Jani Kokkonen <address@hidden>; Crasta Denis-B22176
<address@hidden>; Pathak Arun-B33046 <address@hidden>; Lingli Deng
<address@hidden>; Caraman Mihai Claudiu-B02008 <address@hidden>
Subject: RE: [RFC v1] virtio-crypto specification
Hi Gonglei,
Please find my comments inline.
Regards
Varun
> -----Original Message-----
> From: Gonglei (Arei) [mailto:address@hidden
> Sent: Wednesday, November 25, 2015 1:14 PM
> To: Sethi Varun-B16395 <address@hidden>;
> address@hidden open.org; address@hidden
> Cc: Hanweidong (Randy) <address@hidden>; address@hidden;
> Claudio Fontana <address@hidden>; Huangpeng (Peter)
> <address@hidden>; Lauri Leukkunen
> <address@hidden>; Jani Kokkonen
> <address@hidden>; Crasta Denis-B22176
> <address@hidden>; Pathak Arun-B33046
> <address@hidden>
> Subject: RE: [RFC v1] virtio-crypto specification
>
> Hello Varun,
>
>
> > -----Original Message-----
> > From: Varun Sethi [mailto:address@hidden
> > 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-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
> > 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-accelera
> > to
> > 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: address@hidden
> > [mailto:address@hidden On
> > Behalf Of Gonglei (Arei)
> > Sent: Friday, November 20, 2015 8:58 AM
> > To: address@hidden; address@hidden
> > Cc: Hanweidong (Randy) <address@hidden>; address@hidden;
> > Claudio Fontana <address@hidden>; Huangpeng (Peter)
> > <address@hidden>; Lauri Leukkunen
> > <address@hidden>; Gonglei (Arei)
> > <address@hidden>; Jani Kokkonen <address@hidden>
> > 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.
> >