Re: [Qemu-devel] [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric crypto service

2017-01-18 Thread Gonglei (Arei)
Hi,

> 
> On Wednesday, January 18, 2017 10:04 AM, Gonglei (Arei) wrote:
> > I update the virtio crypto spec to support non-session based crypto
> > Operations and your asym service also needs change struct
> > virtio_crypto_op_data_req which maybe cause the compatibility complaint
> > with the pre-existing code.
> >
> > So I strongly suggest you rebase my v16 (will be submitted today), and put
> > asym service to struct virtio_crypto_op_data_req_mixed.
> >
> 
> Yes, sure.
> 

Besides that, you also need to use new feature bits to control 
changes of struct virtio_crypto_config since I noticed you introduced
some new properties in struct virtio_crypto_config :

\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
@@ -47,6 +47,9 @@ struct virtio_crypto_config {
 le32 mac_algo_l;
 le32 mac_algo_h;
 le32 aead_algo;
+le32 asym_algo;
+/*Rsa padding capabilities*/
+le32 rsa_padding;
 /* Maximum length of cipher key */
 le32 max_cipher_key_len;
 /* Maximum length of authenticated key */

Those changes will break the pre-existing code as well.

Thanks,
-Gonglei

> > struct virtio_crypto_op_data_req_mixed {
> > struct virtio_crypto_op_header header;
> >
> > union {
> > struct virtio_crypto_sym_data_req   sym_req;
> > struct virtio_crypto_hash_data_req  hash_req;
> > struct virtio_crypto_mac_data_req   mac_req;
> > struct virtio_crypto_aead_data_req  aead_req;
> > struct virtio_crypto_sym_data_req_non_sess
> sym_non_sess_req;
> > struct virtio_crypto_hash_data_req_non_sess
> hash_non_sess_req;
> > struct virtio_crypto_mac_data_req_non_sess
> mac_non_sess_req;
> > struct virtio_crypto_aead_data_req_non_sess
> aead_non_sess_req;
> >
> > /* asymmetric crypto requests here */
> > ...
> > } u;
> > };
> >
> > > We also plan to add asymmetric crypto service part support in LKCF
> > > based virtio crypto frontend driver, and upstream DPDK vhost library
> > > based vhost user for cryptodev which also focuses on asymmetric crypto
> > service , any comments?
> > >
> > Sounds great. It's very helpful to accelerate the progress of reviewing.
> > After all they are kinds of special knowledge.
> >
> > Meanwhile, I can submit the cryptodev-vhost-user/cryptodev-vhost-kernel
> > backends in QEMU if needs.
> >
> 
> That's great. We planned to upstream vhost-user for cryptodev to DPDK in Q3
> this year.
> Let's have another collaboration.
> 
> > Thanks,
> > -Gonglei
> >
> 
> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org




Re: [Qemu-devel] [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric crypto service

2017-01-18 Thread Zeng, Xin
On Wednesday, January 18, 2017 10:04 AM, Gonglei (Arei) wrote:
> I update the virtio crypto spec to support non-session based crypto
> Operations and your asym service also needs change struct
> virtio_crypto_op_data_req which maybe cause the compatibility complaint
> with the pre-existing code.
> 
> So I strongly suggest you rebase my v16 (will be submitted today), and put
> asym service to struct virtio_crypto_op_data_req_mixed.
> 

Yes, sure.

> struct virtio_crypto_op_data_req_mixed {
> struct virtio_crypto_op_header header;
> 
> union {
> struct virtio_crypto_sym_data_req   sym_req;
> struct virtio_crypto_hash_data_req  hash_req;
> struct virtio_crypto_mac_data_req   mac_req;
> struct virtio_crypto_aead_data_req  aead_req;
> struct virtio_crypto_sym_data_req_non_sess   sym_non_sess_req;
> struct virtio_crypto_hash_data_req_non_sess  hash_non_sess_req;
> struct virtio_crypto_mac_data_req_non_sess   mac_non_sess_req;
> struct virtio_crypto_aead_data_req_non_sess  aead_non_sess_req;
> 
>   /* asymmetric crypto requests here */
>   ...
> } u;
> };
> 
> > We also plan to add asymmetric crypto service part support in LKCF
> > based virtio crypto frontend driver, and upstream DPDK vhost library
> > based vhost user for cryptodev which also focuses on asymmetric crypto
> service , any comments?
> >
> Sounds great. It's very helpful to accelerate the progress of reviewing.
> After all they are kinds of special knowledge.
> 
> Meanwhile, I can submit the cryptodev-vhost-user/cryptodev-vhost-kernel
> backends in QEMU if needs.
> 

That's great. We planned to upstream vhost-user for cryptodev to DPDK in Q3 
this year. 
Let's have another collaboration.

> Thanks,
> -Gonglei
> 




Re: [Qemu-devel] [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric crypto service

2017-01-17 Thread Gonglei (Arei)
Hi Xin,

>
> Subject: RE: [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric
> crypto service
> 
> Ping...
> Any comments on this part of virtio crypto spec?
> 
I update the virtio crypto spec to support non-session based crypto
Operations and your asym service also needs change struct 
virtio_crypto_op_data_req
which maybe cause the compatibility complaint with the pre-existing code.

So I strongly suggest you rebase my v16 (will be submitted today), and put
asym service to struct virtio_crypto_op_data_req_mixed.

struct virtio_crypto_op_data_req_mixed {
struct virtio_crypto_op_header header;

union {
struct virtio_crypto_sym_data_req   sym_req;
struct virtio_crypto_hash_data_req  hash_req;
struct virtio_crypto_mac_data_req   mac_req;
struct virtio_crypto_aead_data_req  aead_req;
struct virtio_crypto_sym_data_req_non_sess   sym_non_sess_req;
struct virtio_crypto_hash_data_req_non_sess  hash_non_sess_req;
struct virtio_crypto_mac_data_req_non_sess   mac_non_sess_req;
struct virtio_crypto_aead_data_req_non_sess  aead_non_sess_req;

/* asymmetric crypto requests here */
...
} u;
};

> We also plan to add asymmetric crypto service part support in LKCF based 
> virtio
> crypto frontend driver, and upstream DPDK vhost library based vhost user for
> cryptodev which also focuses on asymmetric crypto service , any comments?
> 
Sounds great. It's very helpful to accelerate the progress of reviewing.
After all they are kinds of special knowledge.

Meanwhile, I can submit the cryptodev-vhost-user/cryptodev-vhost-kernel
backends in QEMU if needs.

Thanks,
-Gonglei





Re: [Qemu-devel] [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric crypto service

2017-01-17 Thread Zeng, Xin
Ping...
Any comments on this part of virtio crypto spec?

We also plan to add asymmetric crypto service part support in LKCF based virtio 
crypto frontend driver, and upstream DPDK vhost library based vhost user for 
cryptodev which also focuses on asymmetric crypto service , any comments?

Thanks

> -Original Message-
> From: Zeng, Xin
> Sent: Tuesday, January 10, 2017 8:31 PM
> To: virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
> Cc: m...@redhat.com; arei.gong...@huawei.com; stefa...@redhat.com;
> cornelia.h...@de.ibm.com; Keating, Brian A; Griffin, John; Ma, Liang J;
> weidong.hu...@huawei.com; Zeng, Xin
> Subject: [RFC PATCH v3 1/1] virtio crypto device specification: asymmetric
> crypto service
> 
> This patch introduces asymmetric crypto service into virtio crypto device
> spec. The asymmetric crypto service can be referred as signature,
> verification, encryption, decryption, key generation and key exchange.
> This patch depends on virtio crypto device spec patch:
> http://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00291.html
> 
> Please help to review, thanks!
> 
> Changes since v2:
> - Update some sections according to the update of virtio crypto device spec
> v15.
> - Fix minor spelling mistakes
> - Remove trail spaces in the spec
> 
> Changes since v1:
> - Remove virtio_crypto_buf  to be consistent with other  virtio devices'
> buf representation. [Lei]
> - Use "MUST" instead of "SHOULD" in some places. [Lei]
> 
> Changes since v0:
> - Use devicenormative/drivernormative instead of self-defined
>   device/driver label.  [Lei]
> - Change the error code of verification to general virtio_crypto
>   error code. [Lei]
> - Use macro instead of enum in verification result. [Lei]
> - Fix the incorrect label value for paragraph and section. [Lei]
> 
> Signed-off-by: Xin Zeng 
> ---
>  virtio-crypto.tex | 1109
> -
>  1 file changed, 1107 insertions(+), 2 deletions(-)
> 
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex index 44819f9..d3236df 
> 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -6,7 +6,7 @@ decryption requests are placed in any of teh data active
> queues and are ultimate  backend crypto accelerators. The second kind of
> queue is the control queue used to create  or destroy sessions for symmetric
> algorithms and will control some advanced  features in the future. The virtio
> crypto device provides the following crypto
> -services: CIPHER, MAC, HASH, and AEAD.
> +services: CIPHER, MAC, HASH, AEAD and ASYM.
> 
> 
>  \subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
> @@ -47,6 +47,9 @@ struct virtio_crypto_config {
>  le32 mac_algo_l;
>  le32 mac_algo_h;
>  le32 aead_algo;
> +le32 asym_algo;
> +/*Rsa padding capabilities*/
> +le32 rsa_padding;
>  /* Maximum length of cipher key */
>  le32 max_cipher_key_len;
>  /* Maximum length of authenticated key */ @@ -80,6 +83,8 @@ The
> following services are defined:
>  #define VIRTIO_CRYPTO_SERVICE_MAC2
>  /* AEAD (Authenticated Encryption with Associated Data) service */
>  #define VIRTIO_CRYPTO_SERVICE_AEAD   3
> +/* ASYM (Asymmetric crypto algorithms) service */
> +#define VIRTIO_CRYPTO_SERVICE_ASYM   4
>  \end{lstlisting}
> 
>  The last driver-read-only fields specify detailed algorithms masks @@ -153,6
> +158,28 @@ The following AEAD algorithms are defined:
>  #define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305  3  \end{lstlisting}
> 
> +The following asymmetric algorithms are defined:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_ASYM_NONE   0
> +#define VIRTIO_CRYPTO_ASYM_RSA1
> +#define VIRTIO_CRYPTO_ASYM_DSA2
> +#define VIRTIO_CRYPTO_ASYM_DH 3
> +#define VIRTIO_CRYPTO_ASYM_ECDSA  4
> +#define VIRTIO_CRYPTO_ASYM_ECDH   5
> +\end{lstlisting}
> +
> +The following rsa padding capabilities are defined:
> +
> +\begin{lstlisting}
> +#define VIRTIO_CRYPTO_RSA_NO_PADDING  0
> +#define VIRTIO_CRYPTO_RSA_PKCS1_PADDING   1
> +#define VIRTIO_CRYPTO_RSA_SSLV23_PADDING  2
> +#define VIRTIO_CRYPTO_RSA_PKCS1_OAEP_PADDING  3
> +#define VIRTIO_CRYPTO_RSA_X931_PADDING4
> +#define VIRTIO_CRYPTO_RSA_PKCS1_PSS_PADDING   5
> +\end{lstlisting}
> +
>  \begin{note}
>  Any other value is reserved for future use.
>  \end{note}
> @@ -168,6 +195,7 @@ Any other value is reserved for future use.
>  \item The device MUST set \field{max_size} to show the maximum size of
> crypto request the device supports.
>  \item The device MUST set \field{max_cipher_key_len} to show the
> maximum length of cipher key if the device supports CIPHER service.
>  \item The device MUST set \field{max_auth_key_len} to show the
> maximum length of authenticated key if the device supports MAC service.
> +\item The device MUST set \field{rsa_padding} to show the padding
> capabilities offered by the device.
>  \end{itemize*}
> 
>  \drivernormative{\subsubsection}{Device configuration