[Qemu-devel] [RFC v1] virtio-crypto specification

[Qemu-devel] [RFC v1] virtio-crypto specification

[Gonglei (Arei)]

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.

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Michael S. Tsirkin]

Thanks, looks good overall.
You might want to join the TC if you maintain a device.
Generally, I think this needs a bit more formal conformance
statements.
Some examples below.

On Fri, Nov 20, 2015 at 03:27:51AM +0000, Gonglei (Arei) wrote:
> 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.

In future versions of the specification?

> 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;

You can make this all le too: I don't think we need to
support legacy devices of this type.
Spec also does not use uint8_t.

> };
> 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:

What does this "are supported" mean?
Device SHOULD support 3 types of algorithms?
Or CAN? MUST?

> enum {
>     VIRTIO_CRYPTO_ABLKCIPHER,
>     VIRTIO_CRYPTO_AEAD,
>     VIRTIO_CRYPTO_HASH,
> };

Specify values here too pls.

> 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
> 

I'm guessing backend driver is the device and front-end the driver?


> Note: the front-end driver needs to support both synchronous and asynchronous encryption.

So Driver  MUST support .... ?
Or does this in fact a requirement from device to support
both types.

> Even then the performance is poor in synchronous operation because frequent context switching and virtualization overhead.

So driver SHOULD by preference use asynchronous encryption?

> 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.
> 
> 

needs to be verified -> device MUST verify and MUST return .... ?

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Gonglei (Arei)]

Hi Michael,

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Friday, November 20, 2015 5:40 PM
> 
> Thanks, looks good overall.
> You might want to join the TC if you maintain a device.

Yes, IIRC Jani is a member of the TC, right? Jani ?

> Generally, I think this needs a bit more formal conformance statements.
> Some examples below.
> 
> On Fri, Nov 20, 2015 at 03:27:51AM +0000, Gonglei (Arei) wrote:
> > 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.
> 
> In future versions of the specification?
> 
Yeah, because I just use the controlq to control session operations at present. 

> > 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;
> 
> You can make this all le too: I don't think we need to support legacy devices of
> this type.
> Spec also does not use uint8_t.
> 

Okay, will fix them.

> > };
> > 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:
> 
> What does this "are supported" mean?
> Device SHOULD support 3 types of algorithms?
> Or CAN? MUST?
> 

CAN is more accurate.

> > enum {
> >     VIRTIO_CRYPTO_ABLKCIPHER,
> >     VIRTIO_CRYPTO_AEAD,
> >     VIRTIO_CRYPTO_HASH,
> > };
> 
> Specify values here too pls.
> 
What do you mean here?

> > 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
> >
> 
> I'm guessing backend driver is the device and front-end the driver?
> 

Yes.

> 
> > Note: the front-end driver needs to support both synchronous and
> asynchronous encryption.
> 
> So Driver  MUST support .... ?
> Or does this in fact a requirement from device to support both types.
> 

I mean SHOULD support.
> > Even then the performance is poor in synchronous operation because
> frequent context switching and virtualization overhead.
> 
> So driver SHOULD by preference use asynchronous encryption?
> 
Yes, that's true ;)

> > 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.
> >
> >
> 
> needs to be verified -> device MUST verify and MUST return .... ?
> 
Correct.

Great thanks for your repaid feedback, Michael.

Regards,
-Gonglei

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Jani Kokkonen]

Hi Arei,

Yes, I am member of TC. I will contact you on this topic for further clarification.

-Jani 

-----Original Message-----
From: Gonglei (Arei) 
Sent: Friday, November 20, 2015 11:14 AM
To: Michael S. Tsirkin
Cc: virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org; Jani Kokkonen; Huangpeng (Peter); Claudio Fontana; Hanweidong (Randy); Lauri Leukkunen
Subject: RE: [RFC v1] virtio-crypto specification

Hi Michael,

> -----Original Message-----
> From: Michael S. Tsirkin [mailto:mst@redhat.com]
> Sent: Friday, November 20, 2015 5:40 PM
> 
> Thanks, looks good overall.
> You might want to join the TC if you maintain a device.

Yes, IIRC Jani is a member of the TC, right? Jani ?

> Generally, I think this needs a bit more formal conformance statements.
> Some examples below.
> 
> On Fri, Nov 20, 2015 at 03:27:51AM +0000, Gonglei (Arei) wrote:
> > 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.
> 
> In future versions of the specification?
> 
Yeah, because I just use the controlq to control session operations at present. 

> > 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;
> 
> You can make this all le too: I don't think we need to support legacy 
> devices of this type.
> Spec also does not use uint8_t.
> 

Okay, will fix them.

> > };
> > 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:
> 
> What does this "are supported" mean?
> Device SHOULD support 3 types of algorithms?
> Or CAN? MUST?
> 

CAN is more accurate.

> > enum {
> >     VIRTIO_CRYPTO_ABLKCIPHER,
> >     VIRTIO_CRYPTO_AEAD,
> >     VIRTIO_CRYPTO_HASH,
> > };
> 
> Specify values here too pls.
> 
What do you mean here?

> > 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
> >
> 
> I'm guessing backend driver is the device and front-end the driver?
> 

Yes.

> 
> > Note: the front-end driver needs to support both synchronous and
> asynchronous encryption.
> 
> So Driver  MUST support .... ?
> Or does this in fact a requirement from device to support both types.
> 

I mean SHOULD support.
> > Even then the performance is poor in synchronous operation because
> frequent context switching and virtualization overhead.
> 
> So driver SHOULD by preference use asynchronous encryption?
> 
Yes, that's true ;)

> > 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.
> >
> >
> 
> needs to be verified -> device MUST verify and MUST return .... ?
> 
Correct.

Great thanks for your repaid feedback, Michael.

Regards,
-Gonglei

Re: [Qemu-devel] [virtio-dev] [RFC v1] virtio-crypto specification

[Cornelia Huck]

On Fri, 20 Nov 2015 03:27:51 +0000
"Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:

> 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.

Some further comments from my side, but this looks good generally.

> 
> 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”. 

Any reason you'd want to make this optional? Would it make sense if the
config space field always contains either the maximum size or "0" for
"unlimited"?

> 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.

I'm wondering whether you'll really want a feature bit for each
algorithm. Bits 0-23 are device specific, so there's still some more to
go; but could this also go into the config space instead? It's not like
the driver will want to negotiate which algorithms it wants to use, but
rather it will want to check what the device may offer.

Another thought on negotiable features: The device might provide both a
hardware-backed implementation of (some) APIs and an emulation of
(other) APIs. The driver might, however, want to make sure that a
hardware-backed implementation is used. Would it make sense to add an
negotiable feature bit for allowing software emulation?

> 
> 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;

Anything you have in mind for these?

>     /* 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;

May there be algorithm-specific parameters as well?

> };
> 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:

s/BLK/CRYPTO/ :)

> 
> #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. 

So is it up to the device to execute the operation either synchronously
or asynchronously? Would it make sense if the driver can force one or
the other?

> 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.
> 
> 

Re: [Qemu-devel] [virtio-dev] [RFC v1] virtio-crypto specification

[Gonglei (Arei)]

Hi,

> -----Original Message-----
> From: Cornelia Huck [mailto:cornelia.huck@de.ibm.com]
> Sent: Monday, November 23, 2015 11:14 PM
> Subject: Re: [virtio-dev] [RFC v1] virtio-crypto specification
> 
> On Fri, 20 Nov 2015 03:27:51 +0000
> "Gonglei (Arei)" <arei.gonglei@huawei.com> wrote:
> 
> > 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.
> 
> Some further comments from my side, but this looks good generally.
> 
Thank you so much.

> >
> > 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”.
> 
> Any reason you'd want to make this optional? Would it make sense if the config
> space field always contains either the maximum size or "0" for "unlimited"?
> 
I'm afraid some hardware have max limitation for each single request ;) Maybe it's just used for
memory allocation, TBH I'm not sure. 

But I think your suggestion really make sense.

> > 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.
> 
> I'm wondering whether you'll really want a feature bit for each algorithm. Bits
> 0-23 are device specific, so there's still some more to go; but could this also go
> into the config space instead? It's not like the driver will want to negotiate
> which algorithms it wants to use, but rather it will want to check what the
> device may offer.
> 
If we don't use the feature bit, any other ways can be used by the driver check what the
device offer?

> Another thought on negotiable features: The device might provide both a
> hardware-backed implementation of (some) APIs and an emulation of
> (other) APIs. The driver might, however, want to make sure that a
> hardware-backed implementation is used. Would it make sense to add an
> negotiable feature bit for allowing software emulation?
> 
Nice point :)

> >
> > 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;
> 
> Anything you have in mind for these?
> 
Not yet ;)

> >     /* 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;
> 
> May there be algorithm-specific parameters as well?
> 
Currently, the symmetrical algorithms (cihper, hash and aead) only need those parameters for session creating.
Maybe, the asymmetrical algorithms need some other parameters, so yes.

> > };
> > 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:
> 
> s/BLK/CRYPTO/ :)
> 
Fixed.

> >
> > #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.
> 
> So is it up to the device to execute the operation either synchronously or
> asynchronously? Would it make sense if the driver can force one or the other?
> 
Yes, it is.

You mean the driver can force one to the other according to the device's capability?
Add another feature bit? I think it makes sense.

Regards,
-Gonglei
 
> > 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.
> >
> >

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Varun Sethi]

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-accelerator-gapi-rev02.pdf

We can look at collaborating for the virtio-crypto device definition.

Regards
Varun

-----Original Message-----
From: qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On 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) <hanweidong@huawei.com>; mst@redhat.com; Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) <peter.huangpeng@huawei.com>; Lauri Leukkunen <Lauri.Leukkunen@huawei.com>; Gonglei (Arei) <arei.gonglei@huawei.com>; Jani Kokkonen <Jani.Kokkonen@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.

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Gonglei (Arei)]

Hello Varun,


> -----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 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-accelerator-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. 
 
> We can look at collaborating for the virtio-crypto device definition.
> 

Welcome to join us :)

Regards,
-Gonglei

> Regards
> Varun
> 
> -----Original Message-----
> From: qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org
> [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On
> 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) <hanweidong@huawei.com>; mst@redhat.com;
> Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter)
> <peter.huangpeng@huawei.com>; Lauri Leukkunen
> <Lauri.Leukkunen@huawei.com>; Gonglei (Arei) <arei.gonglei@huawei.com>;
> Jani Kokkonen <Jani.Kokkonen@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.
> 

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Varun Sethi]

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 <Varun.Sethi@freescale.com>; virtio-dev@lists.oasis-
> open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy) <hanweidong@huawei.com>; mst@redhat.com;
> Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter)
> <peter.huangpeng@huawei.com>; Lauri Leukkunen
> <Lauri.Leukkunen@huawei.com>; Jani Kokkonen
> <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176
> <denis.crasta@freescale.com>; Pathak Arun-B33046
> <arun.pathak@freescale.com>
> Subject: RE: [RFC v1] virtio-crypto specification
> 
> Hello Varun,
> 
> 
> > -----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
> > 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.com@nongnu.org
> > [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On
> > 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) <hanweidong@huawei.com>; mst@redhat.com;
> > Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter)
> > <peter.huangpeng@huawei.com>; Lauri Leukkunen
> > <Lauri.Leukkunen@huawei.com>; Gonglei (Arei)
> > <arei.gonglei@huawei.com>; Jani Kokkonen <Jani.Kokkonen@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.
> >

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Denis Crasta]

+Michal and Sebastian.

Denis

-----Original Message-----
From: Sethi Varun-B16395 
Sent: Wednesday, November 25, 2015 4:41 AM
To: Gonglei (Arei) <arei.gonglei@huawei.com>; virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
Cc: Hanweidong (Randy) <hanweidong@huawei.com>; mst@redhat.com; Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) <peter.huangpeng@huawei.com>; Lauri Leukkunen <Lauri.Leukkunen@huawei.com>; Jani Kokkonen <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 <denis.crasta@freescale.com>; Pathak Arun-B33046 <arun.pathak@freescale.com>; Lingli Deng <denglingli@chinamobile.com>; Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Subject: 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 <Varun.Sethi@freescale.com>; 
> virtio-dev@lists.oasis- open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy) <hanweidong@huawei.com>; mst@redhat.com; 
> Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> <Lauri.Leukkunen@huawei.com>; Jani Kokkonen 
> <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 
> <denis.crasta@freescale.com>; Pathak Arun-B33046 
> <arun.pathak@freescale.com>
> Subject: RE: [RFC v1] virtio-crypto specification
> 
> Hello Varun,
> 
> 
> > -----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 
> > 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: qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org
> > [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On 
> > 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) <hanweidong@huawei.com>; mst@redhat.com; 
> > Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> > <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> > <Lauri.Leukkunen@huawei.com>; Gonglei (Arei) 
> > <arei.gonglei@huawei.com>; Jani Kokkonen <Jani.Kokkonen@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.
> >

[Qemu-devel] 答复: [RFC v1] virtio-crypto specification

[Lingli Deng]

Hi Varun,

Thanks for the bridging. 

Hi Gonglei and virtio-crypto guys, 

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. 
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

-----邮件原件-----
发件人: Varun Sethi [mailto:Varun.Sethi@freescale.com] 
发送时间: 2015年11月25日 20:41
收件人: Gonglei (Arei); virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
抄送: Hanweidong (Randy); mst@redhat.com; Claudio Fontana; Huangpeng (Peter); Lauri Leukkunen; Jani Kokkonen; Denis Crasta; Arun Pathak; Lingli Deng; Caraman Mike
主题: 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 <Varun.Sethi@freescale.com>; 
> virtio-dev@lists.oasis- open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy) <hanweidong@huawei.com>; mst@redhat.com; 
> Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> <Lauri.Leukkunen@huawei.com>; Jani Kokkonen 
> <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 
> <denis.crasta@freescale.com>; Pathak Arun-B33046 
> <arun.pathak@freescale.com>
> Subject: RE: [RFC v1] virtio-crypto specification
> 
> Hello Varun,
> 
> 
> > -----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 
> > 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: qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org
> > [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On 
> > 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) <hanweidong@huawei.com>; mst@redhat.com; 
> > Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> > <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> > <Lauri.Leukkunen@huawei.com>; Gonglei (Arei) 
> > <arei.gonglei@huawei.com>; Jani Kokkonen <Jani.Kokkonen@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.
> >

Re: [Qemu-devel] [RFC v1] virtio-crypto specification

[Denis Crasta]

+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 <Varun.Sethi@freescale.com>; 'Gonglei (Arei)' <arei.gonglei@huawei.com>; virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
Cc: 'Hanweidong (Randy)' <hanweidong@huawei.com>; mst@redhat.com; 'Claudio Fontana' <Claudio.Fontana@huawei.com>; 'Huangpeng (Peter)' <peter.huangpeng@huawei.com>; 'Lauri Leukkunen' <Lauri.Leukkunen@huawei.com>; 'Jani Kokkonen' <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 <denis.crasta@freescale.com>; Pathak Arun-B33046 <arun.pathak@freescale.com>; Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Subject: 答复: [RFC v1] virtio-crypto specification

Hi Varun,

Thanks for the bridging. 

Hi Gonglei and virtio-crypto guys, 

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. 
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

-----邮件原件-----
发件人: Varun Sethi [mailto:Varun.Sethi@freescale.com]
发送时间: 2015年11月25日 20:41
收件人: Gonglei (Arei); virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
抄送: Hanweidong (Randy); mst@redhat.com; Claudio Fontana; Huangpeng (Peter); Lauri Leukkunen; Jani Kokkonen; Denis Crasta; Arun Pathak; Lingli Deng; Caraman Mike
主题: 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 <Varun.Sethi@freescale.com>;
> virtio-dev@lists.oasis- open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy) <hanweidong@huawei.com>; mst@redhat.com; 
> Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> <Lauri.Leukkunen@huawei.com>; Jani Kokkonen 
> <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 
> <denis.crasta@freescale.com>; Pathak Arun-B33046 
> <arun.pathak@freescale.com>
> Subject: RE: [RFC v1] virtio-crypto specification
> 
> Hello Varun,
> 
> 
> > -----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 
> > 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: qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org
> > [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On 
> > 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) <hanweidong@huawei.com>; mst@redhat.com; 
> > Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> > <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> > <Lauri.Leukkunen@huawei.com>; Gonglei (Arei) 
> > <arei.gonglei@huawei.com>; Jani Kokkonen <Jani.Kokkonen@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.
> >

[Qemu-devel] 答复: [RFC v1] virtio-crypto specification

[Lingli Deng]

Hi guys,

I am curious about the status of this proposal at OASIS. 
When is it planned for release? Is there any running PoC for the proposal? Is it still open? Any plan for upstreamming?

Thanks,
Lingli

-----邮件原件-----
发件人: Denis Crasta [mailto:denis.crasta@freescale.com] 
发送时间: 2015年11月26日 10:44
收件人: Lingli Deng; Varun Sethi; 'Gonglei (Arei)'; virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
抄送: 'Hanweidong (Randy)'; mst@redhat.com; 'Claudio Fontana'; 'Huangpeng (Peter)'; 'Lauri Leukkunen'; 'Jani Kokkonen'; Arun Pathak; Caraman Mike; Rajesh Kumar Madabushi; Silbermintz Michal; Grigore Sebastian
主题: 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 <Varun.Sethi@freescale.com>; 'Gonglei (Arei)' <arei.gonglei@huawei.com>; virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
Cc: 'Hanweidong (Randy)' <hanweidong@huawei.com>; mst@redhat.com; 'Claudio Fontana' <Claudio.Fontana@huawei.com>; 'Huangpeng (Peter)' <peter.huangpeng@huawei.com>; 'Lauri Leukkunen' <Lauri.Leukkunen@huawei.com>; 'Jani Kokkonen' <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 <denis.crasta@freescale.com>; Pathak Arun-B33046 <arun.pathak@freescale.com>; Caraman Mihai Claudiu-B02008 <B02008@freescale.com>
Subject: 答复: [RFC v1] virtio-crypto specification

Hi Varun,

Thanks for the bridging. 

Hi Gonglei and virtio-crypto guys, 

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. 
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

-----邮件原件-----
发件人: Varun Sethi [mailto:Varun.Sethi@freescale.com]
发送时间: 2015年11月25日 20:41
收件人: Gonglei (Arei); virtio-dev@lists.oasis-open.org; qemu-devel@nongnu.org
抄送: Hanweidong (Randy); mst@redhat.com; Claudio Fontana; Huangpeng (Peter); Lauri Leukkunen; Jani Kokkonen; Denis Crasta; Arun Pathak; Lingli Deng; Caraman Mike
主题: 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 <Varun.Sethi@freescale.com>;
> virtio-dev@lists.oasis- open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy) <hanweidong@huawei.com>; mst@redhat.com; 
> Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> <Lauri.Leukkunen@huawei.com>; Jani Kokkonen 
> <Jani.Kokkonen@huawei.com>; Crasta Denis-B22176 
> <denis.crasta@freescale.com>; Pathak Arun-B33046 
> <arun.pathak@freescale.com>
> Subject: RE: [RFC v1] virtio-crypto specification
> 
> Hello Varun,
> 
> 
> > -----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 
> > 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: qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org
> > [mailto:qemu-devel-bounces+varun.sethi=freescale.com@nongnu.org] On 
> > 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) <hanweidong@huawei.com>; mst@redhat.com; 
> > Claudio Fontana <Claudio.Fontana@huawei.com>; Huangpeng (Peter) 
> > <peter.huangpeng@huawei.com>; Lauri Leukkunen 
> > <Lauri.Leukkunen@huawei.com>; Gonglei (Arei) 
> > <arei.gonglei@huawei.com>; Jani Kokkonen <Jani.Kokkonen@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.
> >