* [Qemu-devel] [PATCH v15 1/2] virtio-crypto: Add virtio crypto device specification
2017-01-04 10:03 [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei
@ 2017-01-04 10:03 ` Gonglei
2017-01-16 13:24 ` Stefan Hajnoczi
2017-01-04 10:03 ` [Qemu-devel] [PATCH v15 2/2] virtio-crypto: Add conformance clauses Gonglei
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ messages in thread
From: Gonglei @ 2017-01-04 10:03 UTC (permalink / raw)
To: qemu-devel, virtio-dev
Cc: luonengjun, mst, cornelia.huck, stefanha, denglingli,
Jani.Kokkonen, Ola.Liljedahl, Varun.Sethi, xin.zeng,
brian.a.keating, liang.j.ma, john.griffin, weidong.huang,
mike.caraman, agraf, claudio.fontana, jianjay.zhou, nmorey,
vincent.jardin, wu.wubin, Shiqing.Fan, arei.gonglei, pasic,
Gonglei, Hanweidong
The virtio crypto device is a virtual crypto device (ie. hardware
crypto accelerator card). Currently, the virtio crypto device provides
the following crypto services: CIPHER, MAC, HASH, and AEAD.
In this patch, CIPHER, MAC, HASH, AEAD services are introduced.
VIRTIO-153
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Cornelia Huck <cornelia.huck@de.ibm.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Lingli Deng <denglingli@chinamobile.com>
CC: Jani Kokkonen <Jani.Kokkonen@huawei.com>
CC: Ola Liljedahl <Ola.Liljedahl@arm.com>
CC: Varun Sethi <Varun.Sethi@freescale.com>
CC: Zeng Xin <xin.zeng@intel.com>
CC: Keating Brian <brian.a.keating@intel.com>
CC: Ma Liang J <liang.j.ma@intel.com>
CC: Griffin John <john.griffin@intel.com>
CC: Hanweidong <hanweidong@huawei.com>
CC: Mihai Claudiu Caraman <mike.caraman@nxp.com>
---
content.tex | 2 +
virtio-crypto.tex | 1029 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 1031 insertions(+)
create mode 100644 virtio-crypto.tex
diff --git a/content.tex b/content.tex
index 4b45678..ab75f78 100644
--- a/content.tex
+++ b/content.tex
@@ -5750,6 +5750,8 @@ descriptor for the \field{sense_len}, \field{residual},
\field{status_qualifier}, \field{status}, \field{response} and
\field{sense} fields.
+\input{virtio-crypto.tex}
+
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
Currently there are three device-independent feature bits defined:
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
new file mode 100644
index 0000000..44819f9
--- /dev/null
+++ b/virtio-crypto.tex
@@ -0,0 +1,1029 @@
+\section{Crypto Device}\label{sec:Device Types / Crypto Device}
+
+The virtio crypto device is a virtual cryptography device as well as a kind of
+virtual hardware accelerator for virtual machines. The encryption and
+decryption requests are placed in any of teh data active queues and are ultimately handled by the
+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.
+
+
+\subsection{Device ID}\label{sec:Device Types / Crypto Device / Device ID}
+
+20
+
+\subsection{Virtqueues}\label{sec:Device Types / Crypto Device / Virtqueues}
+
+\begin{description}
+\item[0] dataq1
+\item[\ldots]
+\item[N-1] dataqN
+\item[N] controlq
+\end{description}
+
+N is set by \field{max_dataqueues}.
+
+\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature bits}
+
+VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is available for CIPHER service.
+VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available for HASH service.
+VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available for MAC service.
+VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available for AEAD service.
+
+\subsection{Device configuration layout}\label{sec:Device Types / Crypto Device / Device configuration layout}
+
+The following driver-read-only configuration fields are defined:
+
+\begin{lstlisting}
+struct virtio_crypto_config {
+ le32 status;
+ le32 max_dataqueues;
+ le32 crypto_services;
+ /* Detailed algorithms mask */
+ le32 cipher_algo_l;
+ le32 cipher_algo_h;
+ le32 hash_algo;
+ le32 mac_algo_l;
+ le32 mac_algo_h;
+ le32 aead_algo;
+ /* Maximum length of cipher key */
+ le32 max_cipher_key_len;
+ /* Maximum length of authenticated key */
+ le32 max_auth_key_len;
+ le32 reserve;
+ /* Maximum size of each crypto request's content */
+ le64 max_size;
+};
+\end{lstlisting}
+
+The value of the \field{status} field is VIRTIO_CRYPTO_S_HW_READY or ~VIRTIO_CRYPTO_S_HW_READY.
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_S_HW_READY (1 << 0)
+\end{lstlisting}
+
+The VIRTIO_CRYPTO_S_HW_READY flag is used to show whether the hardware is ready to work or not.
+
+The following driver-read-only fields include \field{max_dataqueues}, which specifies the
+maximum number of data virtqueues (dataq1\ldots dataqN), and \field{crypto_services},
+which indicates the crypto services the virtio crypto supports.
+
+The following services are defined:
+
+\begin{lstlisting}
+/* CIPHER service */
+#define VIRTIO_CRYPTO_SERVICE_CIPHER 0
+/* HASH service */
+#define VIRTIO_CRYPTO_SERVICE_HASH 1
+/* MAC (Message Authentication Codes) service */
+#define VIRTIO_CRYPTO_SERVICE_MAC 2
+/* AEAD (Authenticated Encryption with Associated Data) service */
+#define VIRTIO_CRYPTO_SERVICE_AEAD 3
+\end{lstlisting}
+
+The last driver-read-only fields specify detailed algorithms masks
+the device offers for corresponding services. The following CIPHER algorithms
+are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_NO_CIPHER 0
+#define VIRTIO_CRYPTO_CIPHER_ARC4 1
+#define VIRTIO_CRYPTO_CIPHER_AES_ECB 2
+#define VIRTIO_CRYPTO_CIPHER_AES_CBC 3
+#define VIRTIO_CRYPTO_CIPHER_AES_CTR 4
+#define VIRTIO_CRYPTO_CIPHER_DES_ECB 5
+#define VIRTIO_CRYPTO_CIPHER_DES_CBC 6
+#define VIRTIO_CRYPTO_CIPHER_3DES_ECB 7
+#define VIRTIO_CRYPTO_CIPHER_3DES_CBC 8
+#define VIRTIO_CRYPTO_CIPHER_3DES_CTR 9
+#define VIRTIO_CRYPTO_CIPHER_KASUMI_F8 10
+#define VIRTIO_CRYPTO_CIPHER_SNOW3G_UEA2 11
+#define VIRTIO_CRYPTO_CIPHER_AES_F8 12
+#define VIRTIO_CRYPTO_CIPHER_AES_XTS 13
+#define VIRTIO_CRYPTO_CIPHER_ZUC_EEA3 14
+\end{lstlisting}
+
+The following HASH algorithms are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_NO_HASH 0
+#define VIRTIO_CRYPTO_HASH_MD5 1
+#define VIRTIO_CRYPTO_HASH_SHA1 2
+#define VIRTIO_CRYPTO_HASH_SHA_224 3
+#define VIRTIO_CRYPTO_HASH_SHA_256 4
+#define VIRTIO_CRYPTO_HASH_SHA_384 5
+#define VIRTIO_CRYPTO_HASH_SHA_512 6
+#define VIRTIO_CRYPTO_HASH_SHA3_224 7
+#define VIRTIO_CRYPTO_HASH_SHA3_256 8
+#define VIRTIO_CRYPTO_HASH_SHA3_384 9
+#define VIRTIO_CRYPTO_HASH_SHA3_512 10
+#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE128 11
+#define VIRTIO_CRYPTO_HASH_SHA3_SHAKE256 12
+\end{lstlisting}
+
+The following MAC algorithms are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_NO_MAC 0
+#define VIRTIO_CRYPTO_MAC_HMAC_MD5 1
+#define VIRTIO_CRYPTO_MAC_HMAC_SHA1 2
+#define VIRTIO_CRYPTO_MAC_HMAC_SHA_224 3
+#define VIRTIO_CRYPTO_MAC_HMAC_SHA_256 4
+#define VIRTIO_CRYPTO_MAC_HMAC_SHA_384 5
+#define VIRTIO_CRYPTO_MAC_HMAC_SHA_512 6
+#define VIRTIO_CRYPTO_MAC_CMAC_3DES 25
+#define VIRTIO_CRYPTO_MAC_CMAC_AES 26
+#define VIRTIO_CRYPTO_MAC_KASUMI_F9 27
+#define VIRTIO_CRYPTO_MAC_SNOW3G_UIA2 28
+#define VIRTIO_CRYPTO_MAC_GMAC_AES 41
+#define VIRTIO_CRYPTO_MAC_GMAC_TWOFISH 42
+#define VIRTIO_CRYPTO_MAC_CBCMAC_AES 49
+#define VIRTIO_CRYPTO_MAC_CBCMAC_KASUMI_F9 50
+#define VIRTIO_CRYPTO_MAC_XCBC_AES 53
+#define VIRTIO_CRYPTO_MAC_ZUC_EIA3 54
+\end{lstlisting}
+
+The following AEAD algorithms are defined:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_NO_AEAD 0
+#define VIRTIO_CRYPTO_AEAD_GCM 1
+#define VIRTIO_CRYPTO_AEAD_CCM 2
+#define VIRTIO_CRYPTO_AEAD_CHACHA20_POLY1305 3
+\end{lstlisting}
+
+\begin{note}
+Any other value is reserved for future use.
+\end{note}
+
+\devicenormative{\subsubsection}{Device configuration layout}{Device Types / Crypto Device / Device configuration layout}
+
+\begin{itemize*}
+\item The device MUST set \field{max_dataqueues} to between 1 and 65535 inclusive.
+\item The device MUST set \field{status} based on the status of the hardware-backed implementation.
+\item The device MUST accept and handle requests after \field{status} is set to VIRTIO_CRYPTO_S_HW_READY.
+\item The device MUST set \field{crypto_services} based on the crypto services the device offers.
+\item The device MUST set detailed algorithms masks based on the \field{crypto_services} field.
+\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.
+\end{itemize*}
+
+\drivernormative{\subsubsection}{Device configuration layout}{Device Types / Crypto Device / Device configuration layout}
+
+\begin{itemize*}
+\item The driver MUST read the ready \field{status} from the bottom bit of status to check whether the hardware-backed
+ implementation is ready or not, and the driver MUST reread it after the device reset.
+\item The driver MUST NOT transmit any packets to the device if the ready \field{status} is not set.
+\item The driver MUST read \field{max_dataqueues} field to discover the number of data queues the device supports.
+\item The driver MUST read \field{crypto_services} field to discover which services the device is able to offer.
+\item The driver MUST read the detailed algorithms fields based on \field{crypto_services} field.
+\item The driver SHOULD read \field{max_size} to discover the maximum size of crypto request the device supports.
+\item The driver SHOULD read \field{max_cipher_key_len} to discover the maximum length of cipher key the device supports.
+\item The driver SHOULD read \field{max_auth_key_len} to discover the maximum length of authenticated key the device supports.
+\end{itemize*}
+
+\subsection{Device Initialization}\label{sec:Device Types / Crypto Device / Device Initialization}
+
+\drivernormative{\subsubsection}{Device Initialization}{Device Types / Crypto Device / Device Initialization}
+
+\begin{itemize*}
+\item The driver MUST identify and initialize the control virtqueue.
+\item The driver MUST read the supported crypto services from bits of \field{crypto_services}.
+\item The driver MUST read the supported algorithms based on \field{crypto_services} field.
+\end{itemize*}
+
+\devicenormative{\subsubsection}{Device Initialization}{Device Types / Crypto Device / Device Initialization}
+
+\begin{itemize*}
+\item The device MUST be configured with at least one accelerator which executes backend crypto operations.
+\item The device MUST write the \field{crypto_services} field based on the capacities of the backend accelerator.
+\end{itemize*}
+
+\subsection{Device Operation}\label{sec:Device Types / Crypto Device / Device Operation}
+
+Packets can be transmitted by placing them in both the controlq and dataq.
+Packets consist of a general header and a service-specific request.
+Where 'general header' is for all crypto requests, and 'service specific requests'
+are composed of operation parameter + output data + input data in general.
+Operation parameters are algorithm-specific parameters, output data is the
+data that should be utilized in operations, and input data is equal to
+"operation result + result data".
+
+The device can support both session mode (See \ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}) and non-session mode, for example,
+As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the driver can use session mode for CIPHER service, otherwise it can only use non-session mode.
+
+\begin{note}
+The basic unit of all data length the byte.
+\end{note}
+
+The general header for controlq is as follows:
+
+\begin{lstlisting}
+#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op))
+
+struct virtio_crypto_ctrl_header {
+#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x02)
+#define VIRTIO_CRYPTO_CIPHER_DESTROY_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x03)
+#define VIRTIO_CRYPTO_HASH_CREATE_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x02)
+#define VIRTIO_CRYPTO_HASH_DESTROY_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x03)
+#define VIRTIO_CRYPTO_MAC_CREATE_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x02)
+#define VIRTIO_CRYPTO_MAC_DESTROY_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x03)
+#define VIRTIO_CRYPTO_AEAD_CREATE_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x02)
+#define VIRTIO_CRYPTO_AEAD_DESTROY_SESSION \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x03)
+ le32 opcode;
+ le32 algo;
+ le32 flag;
+ /* data virtqueue id */
+ le32 queue_id;
+};
+\end{lstlisting}
+
+The general header of dataq:
+
+\begin{lstlisting}
+struct virtio_crypto_op_header {
+#define VIRTIO_CRYPTO_CIPHER_ENCRYPT \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x00)
+#define VIRTIO_CRYPTO_CIPHER_DECRYPT \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x01)
+#define VIRTIO_CRYPTO_HASH \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x00)
+#define VIRTIO_CRYPTO_MAC \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x00)
+#define VIRTIO_CRYPTO_AEAD_ENCRYPT \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
+#define VIRTIO_CRYPTO_AEAD_DECRYPT \
+ VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
+ le32 opcode;
+ /* algo should be service-specific algorithms */
+ le32 algo;
+ /* session_id should be service-specific algorithms */
+ le64 session_id;
+#define VIRTIO_CRYPTO_FLAG_SESSION_MODE 1
+#define VIRTIO_CRYPTO_FLAG_NONE_SESSION_MODE 2
+ /* control flag to control the request */
+ le32 flag;
+ le32 padding;
+};
+\end{lstlisting}
+
+The device can set the operation status as follows: VIRTIO_CRYPTO_OK: success;
+VIRTIO_CRYPTO_ERR: failure or device error; VIRTIO_CRYPTO_NOTSUPP: not supported;
+VIRTIO_CRYPTO_INVSESS: invalid session ID when executing crypto operations.
+
+\begin{lstlisting}
+enum VIRITO_CRYPTO_STATUS {
+ VIRTIO_CRYPTO_OK = 0,
+ VIRTIO_CRYPTO_ERR = 1,
+ VIRTIO_CRYPTO_BADMSG = 2,
+ VIRTIO_CRYPTO_NOTSUPP = 3,
+ VIRTIO_CRYPTO_INVSESS = 4,
+ VIRTIO_CRYPTO_MAX
+};
+\end{lstlisting}
+
+\subsubsection{Control Virtqueue}\label{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue}
+
+The driver uses the control virtqueue to send control commands to the
+device which handles the non-data plane operations, such as session
+operations (See \ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}).
+
+The packet of controlq:
+
+\begin{lstlisting}
+struct virtio_crypto_op_ctrl_req {
+ struct virtio_crypto_ctrl_header header;
+
+ union {
+ struct virtio_crypto_sym_create_session_req sym_create_session;
+ struct virtio_crypto_hash_create_session_req hash_create_session;
+ struct virtio_crypto_mac_create_session_req mac_create_session;
+ struct virtio_crypto_aead_create_session_req aead_create_session;
+ struct virtio_crypto_destroy_session_req destroy_session;
+ } u;
+};
+\end{lstlisting}
+
+The header is the general header, and the union is of the algorithm-specific type,
+which is set by the driver. All the properties in the union are shown as follows.
+
+\paragraph{Session operation}\label{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}
+
+The symmetric algorithms involve the concept of sessions. A session is a
+handle which describes the cryptographic parameters to be applied to
+a number of buffers. The data within a session handle includes the following:
+
+\begin{enumerate}
+\item The operation (CIPHER, HASH/MAC or both, and if both, the order in
+ which the algorithms should be applied).
+\item The CIPHER set data, including the CIPHER algorithm and mode,
+ the key and its length, and the direction (encryption or decryption).
+\item The HASH/MAC set data, including the HASH algorithm or MAC algorithm,
+ and hash result length (to allow for truncation).
+\begin{itemize*}
+\item Authenticated mode can refer to MAC, which requires that the key and
+ its length are also specified.
+\item For nested mode, the inner and outer prefix data and length are specified,
+ as well as the outer HASH algorithm.
+\end{itemize*}
+\end{enumerate}
+
+The following structure stores the result of session creation set by the device:
+
+\begin{lstlisting}
+struct virtio_crypto_session_input {
+ /* Device-writable part */
+ le64 session_id;
+ le32 status;
+ le32 padding;
+};
+\end{lstlisting}
+
+A request to destroy a session includes the following information:
+
+\begin{lstlisting}
+struct virtio_crypto_destroy_session_req {
+ /* Device-readable part */
+ le64 session_id;
+ /* Device-writable part */
+ le32 status;
+ le32 padding;
+};
+\end{lstlisting}
+
+\subparagraph{Session operation: HASH session}\label{sec:Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: HASH session}
+
+The packet of HASH session is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_hash_session_para {
+ /* See VIRTIO_CRYPTO_HASH_* above */
+ le32 algo;
+ /* hash result length */
+ le32 hash_result_len;
+};
+struct virtio_crypto_hash_create_session_req {
+ /* Device-readable part */
+ struct virtio_crypto_hash_session_para para;
+ /* Device-writable part */
+ struct virtio_crypto_session_input input;
+};
+\end{lstlisting}
+
+\subparagraph{Session operation: MAC session}\label{sec:Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: MAC session}
+
+The packet of MAC session is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_mac_session_para {
+ /* See VIRTIO_CRYPTO_MAC_* above */
+ le32 algo;
+ /* hash result length */
+ le32 hash_result_len;
+ /* length of authenticated key */
+ le32 auth_key_len;
+ le32 padding;
+};
+
+struct virtio_crypto_mac_create_session_req {
+ /* Device-readable part */
+ struct virtio_crypto_mac_session_para para;
+ /* The authenticated key */
+ u8 auth_key[auth_key_len];
+
+ /* Device-writable part */
+ struct virtio_crypto_session_input input;
+};
+\end{lstlisting}
+
+\subparagraph{Session operation: Symmetric algorithms session}\label{sec:Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: Symmetric algorithms session}
+
+The request of symmetric session includes two parts, CIPHER algorithms and chain
+algorithms (chaining CIPHER and HASH/MAC). The packet for CIPHER session is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_cipher_session_para {
+ /* See VIRTIO_CRYPTO_CIPHER* above */
+ le32 algo;
+ /* length of key */
+ le32 keylen;
+#define VIRTIO_CRYPTO_OP_ENCRYPT 1
+#define VIRTIO_CRYPTO_OP_DECRYPT 2
+ /* encryption or decryption */
+ le32 op;
+ le32 padding;
+};
+
+struct virtio_crypto_cipher_session_req {
+ /* Device-readable part */
+ struct virtio_crypto_cipher_session_para para;
+ /* The cipher key */
+ u8 cipher_key[keylen];
+
+ /* Device-writable part */
+ struct virtio_crypto_session_input input;
+};
+\end{lstlisting}
+
+The packet for algorithm chaining is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_alg_chain_session_para {
+#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_HASH_THEN_CIPHER 1
+#define VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_CIPHER_THEN_HASH 2
+ le32 alg_chain_order;
+/* Plain hash */
+#define VIRTIO_CRYPTO_SYM_HASH_MODE_PLAIN 1
+/* Authenticated hash (mac) */
+#define VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH 2
+/* Nested hash */
+#define VIRTIO_CRYPTO_SYM_HASH_MODE_NESTED 3
+ le32 hash_mode;
+ struct virtio_crypto_cipher_session_para cipher_param;
+ union {
+ struct virtio_crypto_hash_session_para hash_param;
+ struct virtio_crypto_mac_session_para mac_param;
+ } u;
+ /* length of the additional authenticated data (AAD) in bytes */
+ le32 aad_len;
+ le32 padding;
+};
+
+struct virtio_crypto_alg_chain_session_req {
+ /* Device-readable part */
+ struct virtio_crypto_alg_chain_session_para para;
+ /* The cipher key */
+ u8 cipher_key[keylen];
+ /* The authenticated key */
+ u8 auth_key[auth_key_len];
+
+ /* Device-writable part */
+ struct virtio_crypto_session_input input;
+};
+\end{lstlisting}
+
+The packet for symmetric algorithm is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_sym_create_session_req {
+ union {
+ struct virtio_crypto_cipher_session_req cipher;
+ struct virtio_crypto_alg_chain_session_req chain;
+ } u;
+
+ /* Device-readable part */
+
+/* No operation */
+#define VIRTIO_CRYPTO_SYM_OP_NONE 0
+/* Cipher only operation on the data */
+#define VIRTIO_CRYPTO_SYM_OP_CIPHER 1
+/* Chain any cipher with any hash or mac operation. The order
+ depends on the value of alg_chain_order param */
+#define VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING 2
+ le32 op_type;
+ le32 padding;
+};
+\end{lstlisting}
+
+\subparagraph{Session operation: AEAD session}\label{sec:Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: AEAD session}
+
+The packet for AEAD session is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_aead_session_para {
+ /* See VIRTIO_CRYPTO_AEAD_* above */
+ le32 algo;
+ /* length of key */
+ le32 key_len;
+ /* Authentication tag length */
+ le32 tag_len;
+ /* The length of the additional authenticated data (AAD) in bytes */
+ le32 aad_len;
+ /* encryption or decryption, See above VIRTIO_CRYPTO_OP_* */
+ le32 op;
+ le32 padding;
+};
+
+struct virtio_crypto_aead_create_session_req {
+ /* Device-readable part */
+ struct virtio_crypto_aead_session_para para;
+ u8 key[key_len];
+
+ /* Device-writeable part */
+ struct virtio_crypto_session_input input;
+};
+\end{lstlisting}
+
+\drivernormative{\subparagraph}{Session operation: create session}{Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: create session}
+
+\begin{itemize*}
+\item The driver MUST set the control general header and corresponding properties of the union in structure virtio_crypto_op_ctrl_req. See \ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue}.
+\item The driver MUST set \field{opcode} field based on service type: CIPHER, HASH, MAC, or AEAD.
+\item The driver MUST set \field{queue_id} field to show used dataq.
+\end{itemize*}
+
+\devicenormative{\subparagraph}{Session operation: create session}{Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: create session}
+
+\begin{itemize*}
+\item The device MUST set \field{session_id} field as a session identifier return to the driver when the device finishes processing session creation.
+\item The device MUST set \field{status} field to one of the values of enum VIRITO_CRYPTO_STATUS.
+\end{itemize*}
+
+\drivernormative{\subparagraph}{Session operation: destroy session}{Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: destroy session}
+
+\begin{itemize*}
+\item The driver MUST set \field{opcode} field based on service type: CIPHER, HASH, MAC, or AEAD.
+\item The driver MUST set the \field{session_id} to a valid value which assigned by the device when a session is created.
+\end{itemize*}
+
+\devicenormative{\subparagraph}{Session operation: destroy session}{Device Types / Crypto Device / Device
+Operation / Control Virtqueue / Session operation / Session operation: destroy session}
+
+\begin{itemize*}
+\item The device MUST set \field{status} field to one of the values of enum VIRITO_CRYPTO_STATUS.
+\end{itemize*}
+
+\subsubsection{Data Virtqueue}\label{sec:Device Types / Crypto Device / Device Operation / Data Virtqueue}
+
+The driver uses the data virtqueue to transmit the requests of crypto operation to the device,
+and completes the data plane operations (such as crypto operation).
+
+The packet of dataq is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_op_data_req {
+ 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;
+ } u;
+};
+\end{lstlisting}
+
+The header is the general header and the union is of the algorithm-specific type,
+which is set by the driver. All properties in the union are shown as follows.
+
+There is a unified input header structure for all crypto services.
+
+The structure is defined as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_inhdr {
+ u8 status;
+};
+\end{lstlisting}
+
+\subsubsection{HASH Service Operation}\label{sec:Device Types / Crypto Device / Device Operation / HASH Service Operation}
+
+\begin{lstlisting}
+struct virtio_crypto_hash_para {
+ struct {
+ /* See VIRTIO_CRYPTO_HASH_* above */
+ le32 algo;
+ } sess_para;
+
+ /* length of source data */
+ le32 src_data_len;
+ /* hash result length */
+ le32 hash_result_len;
+ le32 reserved;
+};
+
+struct virtio_crypto_hash_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_hash_para para;
+ /* Source data */
+ u8 src_data[src_data_len];
+
+ /* Device-writable part */
+ /* Hash result data */
+ u8 hash_result[hash_result_len];
+ struct virtio_crypto_inhdr inhdr;
+};
+\end{lstlisting}
+
+Each data request uses virtio_crypto_hash_data_req structure to store information
+used to run the HASH operations.
+
+The information includes the hash parameters stored by \field{para}, output data and input data.
+The output data here includes the source data and the input data includes the hash result data used to save the results of the HASH operations.
+\field{inhdr} stores status of executing the HASH operations.
+
+\drivernormative{\paragraph}{HASH Service Operation}{Device Types / Crypto Device / Device Operation / HASH Service Operation}
+
+\begin{itemize*}
+\item If the VIRTIO_CRYPTO_F_HASH_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_HASH_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_hash_para.sess_para.
+\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_HASH.
+\end{itemize*}
+
+\devicenormative{\paragraph}{HASH Service Operation}{Device Types / Crypto Device / Device Operation / HASH Service Operation}
+
+\begin{itemize*}
+\item The device MUST copy the results of HASH operations to the hash_result[] if HASH operations success.
+\item The device MUST set \field{status} in struct virtio_crypto_inhdr to one of the values of enum VIRITO_CRYPTO_STATUS.
+\end{itemize*}
+
+\subsubsection{MAC Service Operation}\label{sec:Device Types / Crypto Device / Device Operation / MAC Service Operation}
+
+\begin{lstlisting}
+struct virtio_crypto_mac_para {
+ struct {
+ /* See VIRTIO_CRYPTO_MAC_* above */
+ le32 algo;
+ /* length of authenticated key */
+ le32 auth_key_len;
+ } sess_para;
+
+ /* length of source data */
+ le32 src_data_len;
+ /* hash result length */
+ le32 hash_result_len;
+};
+
+struct virtio_crypto_mac_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_mac_para para;
+ /* The authenticated key */
+ u8 auth_key[auth_key_len];
+ /* Source data */
+ u8 src_data[src_data_len];
+
+ /* Device-writable part */
+ /* Hash result data */
+ u8 hash_result[hash_result_len];
+ struct virtio_crypto_inhdr inhdr;
+};
+\end{lstlisting}
+
+Each data request uses virtio_crypto_mac_data_req structure to store information
+used to run the MAC operations.
+
+The information includes the hash parameters stored by \field{para}, output data and input data.
+The output data here includes the source data and the input data includes the hash result data used to save the results of the MAC operations.
+\field{inhdr} stores status of executing the MAC operations.
+
+\drivernormative{\paragraph}{MAC Service Operation}{Device Types / Crypto Device / Device Operation / MAC Service Operation}
+
+\begin{itemize*}
+\item If the VIRTIO_CRYPTO_F_MAC_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_MAC_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_mac_para.sess_para.
+\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_MAC.
+\end{itemize*}
+
+\devicenormative{\paragraph}{MAC Service Operation}{Device Types / Crypto Device / Device Operation / MAC Service Operation}
+
+\begin{itemize*}
+\item The device MUST copy the results of MAC operations to the hash_result[] if HASH operations success.
+\item The device MUST set \field{status} in struct virtio_crypto_inhdr to one of the values of enum VIRITO_CRYPTO_STATUS.
+\end{itemize*}
+
+\subsubsection{Symmetric algorithms Operation}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
+
+The packet of plain CIPHER service is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_cipher_para {
+ struct {
+ /* See VIRTIO_CRYPTO_CIPHER* above */
+ le32 algo;
+ /* length of key */
+ le32 keylen;
+
+ /* See VIRTIO_CRYPTO_OP_* above */
+ le32 op;
+ } sess_para;
+
+ /*
+ * Byte Length of valid IV/Counter data pointed to by the below iv data.
+ *
+ * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
+ * SNOW3G in UEA2 mode, this is the length of the IV (which
+ * must be the same as the block length of the cipher).
+ * For block ciphers in CTR mode, this is the length of the counter
+ * (which must be the same as the block length of the cipher).
+ */
+ le32 iv_len;
+ /* length of source data */
+ le32 src_data_len;
+ /* length of destination data */
+ le32 dst_data_len;
+};
+
+struct virtio_crypto_cipher_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_cipher_para para;
+ /* The cipher key */
+ u8 cipher_key[keylen];
+ /*
+ * Initialization Vector or Counter data.
+ *
+ * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
+ * SNOW3G in UEA2 mode, this is the Initialization Vector (IV)
+ * value.
+ * For block ciphers in CTR mode, this is the counter.
+ * For AES-XTS, this is the 128bit tweak, i, from IEEE Std 1619-2007.
+ *
+ * The IV/Counter will be updated after every partial cryptographic
+ * operation.
+ */
+ u8 iv[iv_len];
+ /* Source data */
+ u8 src_data[src_data_len];
+
+ /* Device-writable part */
+ /* Destination data */
+ u8 dst_data[dst_data_len];
+ struct virtio_crypto_inhdr inhdr;
+};
+\end{lstlisting}
+
+The packet of algorithm chaining is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_alg_chain_data_para {
+ struct {
+ /* See VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_* above */
+ le32 alg_chain_order;
+ /* length of the additional authenticated data in bytes */
+ le32 aad_len;
+
+ struct {
+ /* See VIRTIO_CRYPTO_CIPHER* above */
+ le32 algo;
+ /* length of key */
+ le32 keylen;
+ /* See VIRTIO_CRYPTO_OP_* above */
+ le32 op;
+ } cipher;
+
+ struct {
+ /* See VIRTIO_CRYPTO_HASH_* or VIRTIO_CRYPTO_MAC_* above */
+ le32 algo;
+ /* length of authenticated key */
+ le32 auth_key_len;
+ /* See VIRTIO_CRYPTO_SYM_HASH_MODE_* above */
+ le32 hash_mode;
+ } hash;
+ } sess_para;
+
+ le32 iv_len;
+ /* Length of source data */
+ le32 src_data_len;
+ /* Length of destination data */
+ le32 dst_data_len;
+ /* Starting point for cipher processing in source data */
+ le32 cipher_start_src_offset;
+ /* Length of the source data that the cipher will be computed on */
+ le32 len_to_cipher;
+ /* Starting point for hash processing in source data */
+ le32 hash_start_src_offset;
+ /* Length of the source data that the hash will be computed on */
+ le32 len_to_hash;
+ /* Length of the additional auth data */
+ le32 aad_len;
+ /* Length of the hash result */
+ le32 hash_result_len;
+ le32 reserved;
+};
+
+struct virtio_crypto_alg_chain_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_alg_chain_data_para para;
+ /* The cipher key */
+ u8 cipher_key[keylen];
+ /* The auth key */
+ u8 auth_key[auth_key_len];
+ /* Initialization Vector or Counter data */
+ u8 iv[iv_len];
+ /* Source data */
+ u8 src_data[src_data_len];
+ /* Additional authenticated data if exists */
+ u8 aad[aad_len];
+
+ /* Device-writable part */
+ /* Destination data */
+ u8 dst_data[dst_data_len];
+ /* Hash result data */
+ u8 hash_result[hash_result_len];
+ struct virtio_crypto_inhdr inhdr;
+};
+\end{lstlisting}
+
+The packet of symmetric algorithm is as follows:
+
+\begin{lstlisting}
+struct virtio_crypto_sym_data_req {
+ union {
+ struct virtio_crypto_cipher_data_req cipher;
+ struct virtio_crypto_alg_chain_data_req chain;
+ } u;
+
+ /* Device-readable part */
+
+ /* See above VIRTIO_CRYPTO_SYM_OP_* */
+ le32 op_type;
+ le32 padding;
+};
+\end{lstlisting}
+
+Each data request uses virtio_crypto_sym_data_req structure to store information
+used to run the CIPHER operations.
+
+The information includes the cipher parameters stored by \field{para}, output data and input data.
+In the first virtio_crypto_cipher_para structure, \field{iv_len} specifies the length of the initialization vector or counter,
+\field{src_data_len} specifies the length of the source data, and \field{dst_data_len} specifies the
+length of the destination data.
+For plain CIPHER operations, the output data here includes the IV/Counter data and source data, and the input data includes the destination data used to save the results of the CIPHER operations.
+
+For algorithms chain, the output data here includes the IV/Counter data, source data and additional authenticated data if exists.
+The input data includes both destination data and hash result data used to store the results of the HASH/MAC operations.
+\field{inhdr} stores status of executing the crypto operations.
+
+\drivernormative{\paragraph}{Symmetric algorithms Operation}{Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
+
+\begin{itemize*}
+\item If the VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_cipher_para.sess_para or struct virtio_crypto_alg_chain_data_para.sess_para.
+\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_CIPHER_ENCRYPT or VIRTIO_CRYPTO_CIPHER_DECRYPT.
+\item The driver MUST specify the fields of struct virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the packet is based on VIRTIO_CRYPTO_SYM_OP_CIPHER.
+\item The driver MUST specify the fields of both struct virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the packet
+ is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type and in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
+\end{itemize*}
+
+\devicenormative{\paragraph}{Symmetric algorithms Operation}{Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
+
+\begin{itemize*}
+\item The device MUST parse \field{flag} field in struct virtio_crypto_op_header in order to decide which mode the driver uses.
+\item The device MUST parse the virtio_crypto_sym_data_req based on the \field{opcode} in general header.
+\item The device SHOULD only parse fields of struct virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the packet is VIRTIO_CRYPTO_SYM_OP_CIPHER type.
+\item The device MUST parse fields of both struct virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the packet
+ is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
+\item The device MUST copy the result of cryptographic operation to the dst_data[] in both plain CIPHER mode and algorithms chain mode.
+\item The device MUST check the \field{para}.\field{add_len} is bigger than 0 before parse the additional authenticated data in plain algorithms chain mode.
+\item The device MUST copy the result of HASH/MAC operation to the hash_result[] is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
+\item The device MUST set the \field{status} field in struct virtio_crypto_inhdr to one of the values of enum VIRITO_CRYPTO_STATUS.
+\end{itemize*}
+
+\paragraph{Steps of Operation}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation / Steps of Operation}
+
+\subparagraph{Step1: Create session}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation / Steps of Operation / Step1: Create session if using session mode}
+
+\begin{enumerate}
+\item The driver specifies information in struct virtio_crypto_op_ctrl_req, including the algorithm name, key, keylen etc;
+\item The driver adds the request of session creation into the controlq's Vring Descriptor Table;
+\item The driver kicks the device;
+\item The device receives the request from controlq;
+\item The device parses information about the request, and determines the information concerning the backend crypto accelerator;
+\item The device packs information based on the APIs of the backend crypto accelerator;
+\item The device invokes the session creation APIs of the backend crypto accelerator to create a session;
+\item The device returns the session id to the driver.
+\end{enumerate}
+
+\subparagraph{Step2: Execute cryptographic operation}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation / Steps of Operation / Step2: Execute cryptographic operation}
+
+\begin{enumerate}
+\item The driver specifies information in struct virtio_crypto_op_data_req, including struct virtio_crypto_op_header and struct virtio_crypto_sym_data_req, see \ref{sec:Device Types / Crypto Device / Device
+ Operation / Symmetric algorithms Operation};
+\item The driver adds the request for cryptographic operation into the dataq's Vring Descriptor Table;
+\item The driver kicks the device (Or the device actively polls the dataq's Vring Descriptor Table);
+\item The device receives the request from dataq;
+\item The device parses information about the request, and determines the identification information for the backend crypto accelerator. For example, converting guest physical addresses to host physical addresses;
+\item The device packs identification information based on the API of the backend crypto accelerator;
+\item The device invokes the cryptographic APIs of the backend crypto accelerator;
+\item The backend crypto accelerator executes the cryptographic operation implicitly;
+\item The device receives the cryptographic results from the backend crypto accelerator (synchronous or asynchronous);
+\item The device sets the \field{status} in struct virtio_crypto_inhdr;
+\item The device updates and flushes the Used Ring to return the cryptographic results to the driver;
+\item The device notifies the driver (Or the driver actively polls the dataq's Used Ring);
+\item The driver saves the cryptographic results.
+\end{enumerate}
+
+\begin{note}
+\begin{itemize*}
+\item For better performance, the device should by preference use vhost scheme (user space or kernel space)
+ as the backend crypto accelerator in the real production environment.
+\end{itemize*}
+\end{note}
+
+\subsubsection{AEAD Service Operation}\label{sec:Device Types / Crypto Device / Device Operation / AEAD Service Operation}
+
+\begin{lstlisting}
+struct virtio_crypto_aead_para {
+ struct {
+ /* See VIRTIO_CRYPTO_AEAD_* above */
+ le32 algo;
+ /* length of key */
+ le32 key_len;
+ /* encrypt or decrypt, See above VIRTIO_CRYPTO_OP_* */
+ le32 op;
+ } sess_para;
+
+ /*
+ * Byte Length of valid IV data.
+ *
+ * For GCM mode, this is either 12 (for 96-bit IVs) or 16, in which
+ * case iv points to J0.
+ * For CCM mode, this is the length of the nonce, which can be in the
+ * range 7 to 13 inclusive.
+ */
+ le32 iv_len;
+ /* Authentication tag length */
+ le32 tag_len;
+ /* length of additional auth data */
+ le32 aad_len;
+ /* length of source data */
+ le32 src_data_len;
+ /* length of dst data, this should be at least src_data_len + tag_len */
+ le32 dst_data_len;
+};
+
+struct virtio_crypto_aead_data_req {
+ /* Device-readable part */
+ struct virtio_crypto_aead_para para;
+ /* The cipher key */
+ u8 key[key_len];
+ /*
+ * Initialization Vector data.
+ *
+ * For GCM mode, this is either the IV (if the length is 96 bits) or J0
+ * (for other sizes), where J0 is as defined by NIST SP800-38D.
+ * Regardless of the IV length, a full 16 bytes needs to be allocated.
+ * For CCM mode, the first byte is reserved, and the nonce should be
+ * written starting at &iv[1] (to allow space for the implementation
+ * to write in the flags in the first byte). Note that a full 16 bytes
+ * should be allocated, even though the iv_len field will have
+ * a value less than this.
+ *
+ * The IV will be updated after every partial cryptographic operation.
+ */
+ u8 iv[iv_len];
+ /* Source data */
+ u8 src_data[src_data_len];
+ /* Additional authenticated data if exists */
+ u8 aad[aad_len];
+
+ /* Device-writable part */
+ /* Pointer to output data */
+ u8 dst_data[dst_data_len];
+
+ struct virtio_crypto_inhdr inhdr;
+};
+\end{lstlisting}
+
+Each data request uses virtio_crypto_aead_data_req structure to store information
+used to run the AEAD operations.
+
+The information includes the hash parameters stored by \field{para}, output data and input data.
+In the first virtio_crypto_aead_para structure, \field{iv_len} specifies the length of the initialization vector. \field{tag_len} specifies the length of the authentication tag;
+\field{aad_len} specifies the length of additional authentication data, \field{src_data_len} specifies the
+length of the source data; \field{dst_data_len} specifies the length of the destination data, which is at least \field{src_data_len} + \field{tag_len}.
+
+The output data here includes the IV/Counter data, source data and additional authenticated data if exists.
+The input data includes both destination data used to save the results of the AEAD operations.
+\field{inhdr} stores status of executing the AEAD operations.
+
+\drivernormative{\paragraph}{AEAD Service Operation}{Device Types / Crypto Device / Device Operation / AEAD Service Operation}
+
+\begin{itemize*}
+\item If the VIRTIO_CRYPTO_F_AEAD_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_AEAD_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_aead_para.sess_para.
+\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_AEAD_ENCRYPT or VIRTIO_CRYPTO_AEAD_DECRYPT.
+\end{itemize*}
+
+\devicenormative{\paragraph}{AEAD Service Operation}{Device Types / Crypto Device / Device Operation / AEAD Service Operation}
+
+\begin{itemize*}
+\item The device MUST parse the virtio_crypto_aead_data_req based on the \field{opcode} in general header.
+\item The device MUST copy the result of cryptographic operation to the dst_data[].
+\item The device MUST copy the authentication tag to the dst_data[] offset the cipher result.
+\item The device MUST set the \field{status} field in struct virtio_crypto_inhdr to one of the values of enum VIRITO_CRYPTO_STATUS.
+\item When the \field{opcode} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device MUST verify and return the verification result to the driver, and if the verification result is incorrect, VIRTIO_CRYPTO_BADMSG (bad message) MUST be returned to the driver.
+\end{itemize*}
\ No newline at end of file
--
1.7.12.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [PATCH v15 1/2] virtio-crypto: Add virtio crypto device specification
2017-01-04 10:03 ` [Qemu-devel] [PATCH v15 1/2] virtio-crypto: Add " Gonglei
@ 2017-01-16 13:24 ` Stefan Hajnoczi
2017-01-17 1:23 ` Gonglei (Arei)
0 siblings, 1 reply; 18+ messages in thread
From: Stefan Hajnoczi @ 2017-01-16 13:24 UTC (permalink / raw)
To: Gonglei
Cc: qemu-devel, virtio-dev, weidong.huang, mst, john.griffin,
cornelia.huck, jianjay.zhou, Varun.Sethi, denglingli,
arei.gonglei, Hanweidong, agraf, nmorey, vincent.jardin,
Ola.Liljedahl, luonengjun, xin.zeng, liang.j.ma, stefanha,
Shiqing.Fan, Jani.Kokkonen, pasic, brian.a.keating,
claudio.fontana, mike.caraman, wu.wubin
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
On Wed, Jan 04, 2017 at 06:03:04PM +0800, Gonglei wrote:
> +The general header of dataq:
> +
> +\begin{lstlisting}
> +struct virtio_crypto_op_header {
> +#define VIRTIO_CRYPTO_CIPHER_ENCRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x00)
> +#define VIRTIO_CRYPTO_CIPHER_DECRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x01)
> +#define VIRTIO_CRYPTO_HASH \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x00)
> +#define VIRTIO_CRYPTO_MAC \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x00)
> +#define VIRTIO_CRYPTO_AEAD_ENCRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> +#define VIRTIO_CRYPTO_AEAD_DECRYPT \
> + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> + le32 opcode;
> + /* algo should be service-specific algorithms */
> + le32 algo;
> + /* session_id should be service-specific algorithms */
> + le64 session_id;
> +#define VIRTIO_CRYPTO_FLAG_SESSION_MODE 1
> +#define VIRTIO_CRYPTO_FLAG_NONE_SESSION_MODE 2
This constant isn't mentioned anywhere in the spec, am I missing
something?
Regarding naming: "none session mode" != "non-session mode"
I think this constant should be called
VIRTIO_CRYPTO_FLAG_NON_SESSION_MODE or
VIRTIO_CRYPTO_FLAG_SESSIONLESS_MODE.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [PATCH v15 1/2] virtio-crypto: Add virtio crypto device specification
2017-01-16 13:24 ` Stefan Hajnoczi
@ 2017-01-17 1:23 ` Gonglei (Arei)
0 siblings, 0 replies; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-17 1:23 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
Huangweidong (C), mst@redhat.com, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, Hanweidong (Randy), agraf@suse.de,
nmorey@kalray.eu, vincent.jardin@6wind.com, Ola.Liljedahl@arm.com,
Luonengjun, xin.zeng@intel.com, liang.j.ma@intel.com,
stefanha@redhat.com, Shiqing Fan, Jani Kokkonen,
pasic@linux.vnet.ibm.com, brian.a.keating@intel.com,
Claudio Fontana, mike.caraman@nxp.com, Wubin (H)
Hi Stefan,
>
> On Wed, Jan 04, 2017 at 06:03:04PM +0800, Gonglei wrote:
> > +The general header of dataq:
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_op_header {
> > +#define VIRTIO_CRYPTO_CIPHER_ENCRYPT \
> > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x00)
> > +#define VIRTIO_CRYPTO_CIPHER_DECRYPT \
> > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_CIPHER, 0x01)
> > +#define VIRTIO_CRYPTO_HASH \
> > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_HASH, 0x00)
> > +#define VIRTIO_CRYPTO_MAC \
> > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_MAC, 0x00)
> > +#define VIRTIO_CRYPTO_AEAD_ENCRYPT \
> > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x00)
> > +#define VIRTIO_CRYPTO_AEAD_DECRYPT \
> > + VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AEAD, 0x01)
> > + le32 opcode;
> > + /* algo should be service-specific algorithms */
> > + le32 algo;
> > + /* session_id should be service-specific algorithms */
> > + le64 session_id;
> > +#define VIRTIO_CRYPTO_FLAG_SESSION_MODE 1
> > +#define VIRTIO_CRYPTO_FLAG_NONE_SESSION_MODE 2
>
> This constant isn't mentioned anywhere in the spec, am I missing
> something?
>
> Regarding naming: "none session mode" != "non-session mode"
>
> I think this constant should be called
> VIRTIO_CRYPTO_FLAG_NON_SESSION_MODE or
> VIRTIO_CRYPTO_FLAG_SESSIONLESS_MODE.
Sorry for my typo, I used VIRTIO_CRYPTO_FLAG_NON_SESSION_MODE.
Thanks,
-Gonglei
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Qemu-devel] [PATCH v15 2/2] virtio-crypto: Add conformance clauses
2017-01-04 10:03 [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei
2017-01-04 10:03 ` [Qemu-devel] [PATCH v15 1/2] virtio-crypto: Add " Gonglei
@ 2017-01-04 10:03 ` Gonglei
2017-01-04 10:10 ` [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei (Arei)
2017-01-12 11:27 ` [Qemu-devel] " Gonglei (Arei)
3 siblings, 0 replies; 18+ messages in thread
From: Gonglei @ 2017-01-04 10:03 UTC (permalink / raw)
To: qemu-devel, virtio-dev
Cc: luonengjun, mst, cornelia.huck, stefanha, denglingli,
Jani.Kokkonen, Ola.Liljedahl, Varun.Sethi, xin.zeng,
brian.a.keating, liang.j.ma, john.griffin, weidong.huang,
mike.caraman, agraf, claudio.fontana, jianjay.zhou, nmorey,
vincent.jardin, wu.wubin, Shiqing.Fan, arei.gonglei, pasic,
Gonglei
Add the conformance targets and clauses for
virtio-crypto device.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
---
conformance.tex | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/conformance.tex b/conformance.tex
index f59e360..3bde4b6 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -146,6 +146,21 @@ An SCSI host driver MUST conform to the following normative statements:
\item \ref{drivernormative:Device Types / SCSI Host Device / Device Operation / Device Operation: eventq}
\end{itemize}
+\subsection{Crypto Driver Conformance}\label{sec:Conformance / Driver Conformance / Crypto Driver Conformance}
+
+An Crypto driver MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{drivernormative:Device Types / Crypto Device / Device configuration layout}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Initialization}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: create session}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: destroy session}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / HASH Service operation}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / MAC Service operation}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / AEAD Service operation}
+\end{itemize}
+
\section{Device Conformance}\label{sec:Conformance / Device Conformance}
A device MUST conform to the following normative statements:
@@ -267,6 +282,21 @@ An SCSI host device MUST conform to the following normative statements:
\item \ref{devicenormative:Device Types / SCSI Host Device / Device Operation / Device Operation: eventq}
\end{itemize}
+\subsection{Crypto Device Conformance}\label{sec:Conformance / Device Conformance / Crypto Device Conformance}
+
+An Crypto device MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{devicenormative:Device Types / Crypto Device / Device configuration layout}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Initialization}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: create session}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation / Session operation: destroy session}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / HASH Service operation}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / MAC Service operation}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / AEAD Service operation}
+\end{itemize}
+
\section{Legacy Interface: Transitional Device and
Transitional Driver Conformance}\label{sec:Conformance / Legacy
Interface: Transitional Device and
--
1.7.12.4
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-04 10:03 [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei
2017-01-04 10:03 ` [Qemu-devel] [PATCH v15 1/2] virtio-crypto: Add " Gonglei
2017-01-04 10:03 ` [Qemu-devel] [PATCH v15 2/2] virtio-crypto: Add conformance clauses Gonglei
@ 2017-01-04 10:10 ` Gonglei (Arei)
2017-01-12 11:58 ` Halil Pasic
2017-01-12 11:27 ` [Qemu-devel] " Gonglei (Arei)
3 siblings, 1 reply; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-04 10:10 UTC (permalink / raw)
To: Gonglei (Arei), qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org
Cc: Luonengjun, mst@redhat.com, cornelia.huck@de.ibm.com,
stefanha@redhat.com, denglingli@chinamobile.com, Jani Kokkonen,
Ola.Liljedahl@arm.com, Varun.Sethi@freescale.com,
xin.zeng@intel.com, brian.a.keating@intel.com,
liang.j.ma@intel.com, john.griffin@intel.com, Huangweidong (C),
mike.caraman@nxp.com, agraf@suse.de, Claudio Fontana,
Zhoujian (jay, Euler), nmorey@kalray.eu, vincent.jardin@6wind.com,
Wubin (H), Shiqing Fan, arei.gonglei@hotmail.com,
pasic@linux.vnet.ibm.com
Hi all,
I attach the diff files between v14 and v15 for better review.
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 9f7faf0..884ee95 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -2,8 +2,8 @@
The virtio crypto device is a virtual cryptography device as well as a kind of
virtual hardware accelerator for virtual machines. The encryption and
-decryption requests are placed in the data queue and are ultimately handled by the
-backend crypto accelerators. The second queue is the control queue used to create
+decryption requests are placed in any of the data active queues and are ultimately handled by the
+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.
@@ -26,7 +26,7 @@ N is set by \field{max_dataqueues}.
\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature bits}
-Undefined currently.
+None currently defined.
\subsection{Device configuration layout}\label{sec:Device Types / Crypto Device / Device configuration layout}
@@ -54,13 +54,14 @@ struct virtio_crypto_config {
};
\end{lstlisting}
-The value of the \field{status} field is VIRTIO_CRYPTO_S_HW_READY or VIRTIO_CRYPTO_S_STARTED.
+The value of the \field{status} field is VIRTIO_CRYPTO_S_HW_READY or ~VIRTIO_CRYPTO_S_HW_READY.
\begin{lstlisting}
#define VIRTIO_CRYPTO_S_HW_READY (1 << 0)
-#define VIRTIO_CRYPTO_S_STARTED (1 << 1)
\end{lstlisting}
+The VIRTIO_CRYPTO_S_HW_READY flag is used to show whether the hardware is ready to work or not.
+
The following driver-read-only fields include \field{max_dataqueues}, which specifies the
maximum number of data virtqueues (dataq1\ldots dataqN), and \field{crypto_services},
which indicates the crypto services the virtio crypto supports.
@@ -172,7 +173,7 @@ Any other value is reserved for future use.
\item The driver MUST read the ready \field{status} from the bottom bit of status to check whether the hardware-backed
implementation is ready or not, and the driver MUST reread it after the device reset.
\item The driver MUST NOT transmit any packets to the device if the ready \field{status} is not set.
-\item The driver MAY read \field{max_dataqueues} field to discover the number of data queues the device supports.
+\item The driver MUST read \field{max_dataqueues} field to discover the number of data queues the device supports.
\item The driver MUST read \field{crypto_services} field to discover which services the device is able to offer.
\item The driver MUST read the detailed algorithms fields based on \field{crypto_services} field.
\item The driver SHOULD read \field{max_size} to discover the maximum size of crypto request the device supports.
===============The below diff shows the changes of add non-session mode support:
diff --git a/virtio-crypto.tex b/virtio-crypto.tex
index 884ee95..44819f9 100644
--- a/virtio-crypto.tex
+++ b/virtio-crypto.tex
@@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
\subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature bits}
-None currently defined.
+VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is available for CIPHER service.
+VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available for HASH service.
+VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available for MAC service.
+VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available for AEAD service.
\subsection{Device configuration layout}\label{sec:Device Types / Crypto Device / Device configuration layout}
@@ -208,6 +211,9 @@ Operation parameters are algorithm-specific parameters, output data is the
data that should be utilized in operations, and input data is equal to
"operation result + result data".
+The device can support both session mode (See \ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}) and non-session mode, for example,
+As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the driver can use session mode for CIPHER service, otherwise it can only use non-session mode.
+
\begin{note}
The basic unit of all data length the byte.
\end{note}
@@ -263,6 +269,8 @@ struct virtio_crypto_op_header {
le32 algo;
/* session_id should be service-specific algorithms */
le64 session_id;
+#define VIRTIO_CRYPTO_FLAG_SESSION_MODE 1
+#define VIRTIO_CRYPTO_FLAG_NONE_SESSION_MODE 2
/* control flag to control the request */
le32 flag;
le32 padding;
@@ -501,11 +509,11 @@ struct virtio_crypto_aead_session_para {
le32 algo;
/* length of key */
le32 key_len;
- /* hash result length */
- le32 hash_result_len;
+ /* Authentication tag length */
+ le32 tag_len;
/* The length of the additional authenticated data (AAD) in bytes */
le32 aad_len;
- /* encryption or decryption, See above VIRTIO_CRYPTO_* */
+ /* encryption or decryption, See above VIRTIO_CRYPTO_OP_* */
le32 op;
le32 padding;
};
@@ -588,10 +596,16 @@ struct virtio_crypto_inhdr {
\begin{lstlisting}
struct virtio_crypto_hash_para {
+ struct {
+ /* See VIRTIO_CRYPTO_HASH_* above */
+ le32 algo;
+ } sess_para;
+
/* length of source data */
le32 src_data_len;
/* hash result length */
le32 hash_result_len;
+ le32 reserved;
};
struct virtio_crypto_hash_data_req {
@@ -617,9 +631,11 @@ The output data here includes the source data and the input data includes the ha
\drivernormative{\paragraph}{HASH Service Operation}{Device Types / Crypto Device / Device Operation / HASH Service Operation}
\begin{itemize*}
-\item The driver MUST set the \field{session_id} in struct virtio_crypto_op_header to a valid value which assigned by the device when a session is created.
+\item If the VIRTIO_CRYPTO_F_HASH_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_HASH_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_hash_para.sess_para.
\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_HASH.
-\item The driver MUST set the \field{queue_id} field to show used dataq in struct virtio_crypto_op_header.
\end{itemize*}
\devicenormative{\paragraph}{HASH Service Operation}{Device Types / Crypto Device / Device Operation / HASH Service Operation}
@@ -633,12 +649,24 @@ The output data here includes the source data and the input data includes the ha
\begin{lstlisting}
struct virtio_crypto_mac_para {
- struct virtio_crypto_hash_para hash;
+ struct {
+ /* See VIRTIO_CRYPTO_MAC_* above */
+ le32 algo;
+ /* length of authenticated key */
+ le32 auth_key_len;
+ } sess_para;
+
+ /* length of source data */
+ le32 src_data_len;
+ /* hash result length */
+ le32 hash_result_len;
};
struct virtio_crypto_mac_data_req {
/* Device-readable part */
struct virtio_crypto_mac_para para;
+ /* The authenticated key */
+ u8 auth_key[auth_key_len];
/* Source data */
u8 src_data[src_data_len];
@@ -659,9 +687,11 @@ The output data here includes the source data and the input data includes the ha
\drivernormative{\paragraph}{MAC Service Operation}{Device Types / Crypto Device / Device Operation / MAC Service Operation}
\begin{itemize*}
-\item The driver MUST set the \field{session_id} in struct virtio_crypto_op_header to a valid value which assigned by the device when a session is created.
+\item If the VIRTIO_CRYPTO_F_MAC_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_MAC_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_mac_para.sess_para.
\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_MAC.
-\item The driver MUST set the \field{queue_id} field to show used dataq in struct virtio_crypto_op_header.
\end{itemize*}
\devicenormative{\paragraph}{MAC Service Operation}{Device Types / Crypto Device / Device Operation / MAC Service Operation}
@@ -677,6 +707,16 @@ The packet of plain CIPHER service is as follows:
\begin{lstlisting}
struct virtio_crypto_cipher_para {
+ struct {
+ /* See VIRTIO_CRYPTO_CIPHER* above */
+ le32 algo;
+ /* length of key */
+ le32 keylen;
+
+ /* See VIRTIO_CRYPTO_OP_* above */
+ le32 op;
+ } sess_para;
+
/*
* Byte Length of valid IV/Counter data pointed to by the below iv data.
*
@@ -691,12 +731,13 @@ struct virtio_crypto_cipher_para {
le32 src_data_len;
/* length of destination data */
le32 dst_data_len;
- le32 padding;
};
struct virtio_crypto_cipher_data_req {
/* Device-readable part */
struct virtio_crypto_cipher_para para;
+ /* The cipher key */
+ u8 cipher_key[keylen];
/*
* Initialization Vector or Counter data.
*
@@ -724,6 +765,31 @@ The packet of algorithm chaining is as follows:
\begin{lstlisting}
struct virtio_crypto_alg_chain_data_para {
+ struct {
+ /* See VIRTIO_CRYPTO_SYM_ALG_CHAIN_ORDER_* above */
+ le32 alg_chain_order;
+ /* length of the additional authenticated data in bytes */
+ le32 aad_len;
+
+ struct {
+ /* See VIRTIO_CRYPTO_CIPHER* above */
+ le32 algo;
+ /* length of key */
+ le32 keylen;
+ /* See VIRTIO_CRYPTO_OP_* above */
+ le32 op;
+ } cipher;
+
+ struct {
+ /* See VIRTIO_CRYPTO_HASH_* or VIRTIO_CRYPTO_MAC_* above */
+ le32 algo;
+ /* length of authenticated key */
+ le32 auth_key_len;
+ /* See VIRTIO_CRYPTO_SYM_HASH_MODE_* above */
+ le32 hash_mode;
+ } hash;
+ } sess_para;
+
le32 iv_len;
/* Length of source data */
le32 src_data_len;
@@ -747,6 +813,10 @@ struct virtio_crypto_alg_chain_data_para {
struct virtio_crypto_alg_chain_data_req {
/* Device-readable part */
struct virtio_crypto_alg_chain_data_para para;
+ /* The cipher key */
+ u8 cipher_key[keylen];
+ /* The auth key */
+ u8 auth_key[auth_key_len];
/* Initialization Vector or Counter data */
u8 iv[iv_len];
/* Source data */
@@ -783,11 +853,11 @@ struct virtio_crypto_sym_data_req {
Each data request uses virtio_crypto_sym_data_req structure to store information
used to run the CIPHER operations.
-The information includes the hash parameters stored by \field{para}, output data and input data.
+The information includes the cipher parameters stored by \field{para}, output data and input data.
In the first virtio_crypto_cipher_para structure, \field{iv_len} specifies the length of the initialization vector or counter,
\field{src_data_len} specifies the length of the source data, and \field{dst_data_len} specifies the
length of the destination data.
-For plain CIPHER operations, the output data here includes the IV/Counter data and source data, and the input data includes the destination data used to save the results of the CIPHER operations.
+For plain CIPHER operations, the output data here includes the IV/Counter data and source data, and the input data includes the destination data used to save the results of the CIPHER operations.
For algorithms chain, the output data here includes the IV/Counter data, source data and additional authenticated data if exists.
The input data includes both destination data and hash result data used to store the results of the HASH/MAC operations.
@@ -796,21 +866,24 @@ The input data includes both destination data and hash result data used to store
\drivernormative{\paragraph}{Symmetric algorithms Operation}{Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
\begin{itemize*}
-\item The driver MUST set the \field{session_id} in struct virtio_crypto_op_header to a valid value which assigned by the device when a session is created.
+\item If the VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_cipher_para.sess_para or struct virtio_crypto_alg_chain_data_para.sess_para.
\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_CIPHER_ENCRYPT or VIRTIO_CRYPTO_CIPHER_DECRYPT.
-\item The driver MUST set the \field{queue_id} field to show used dataq in struct virtio_crypto_op_header.
-\item The driver MUST specify the fields of struct virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the created session is based on VIRTIO_CRYPTO_SYM_OP_CIPHER.
-\item The driver MUST specify the fields of both struct virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the created session
-\item is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type and in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
+\item The driver MUST specify the fields of struct virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the packet is based on VIRTIO_CRYPTO_SYM_OP_CIPHER.
+\item The driver MUST specify the fields of both struct virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the packet
+ is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type and in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
\end{itemize*}
\devicenormative{\paragraph}{Symmetric algorithms Operation}{Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation}
\begin{itemize*}
+\item The device MUST parse \field{flag} field in struct virtio_crypto_op_header in order to decide which mode the driver uses.
\item The device MUST parse the virtio_crypto_sym_data_req based on the \field{opcode} in general header.
-\item The device SHOULD only parse fields of struct virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the created session is VIRTIO_CRYPTO_SYM_OP_CIPHER type.
-\item The device MUST parse fields of both struct virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the created
-session is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
+\item The device SHOULD only parse fields of struct virtio_crypto_cipher_data_req in struct virtio_crypto_sym_data_req if the packet is VIRTIO_CRYPTO_SYM_OP_CIPHER type.
+\item The device MUST parse fields of both struct virtio_crypto_cipher_data_req and struct virtio_crypto_mac_data_req in struct virtio_crypto_sym_data_req if the packet
+ is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and in the VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH mode.
\item The device MUST copy the result of cryptographic operation to the dst_data[] in both plain CIPHER mode and algorithms chain mode.
\item The device MUST check the \field{para}.\field{add_len} is bigger than 0 before parse the additional authenticated data in plain algorithms chain mode.
\item The device MUST copy the result of HASH/MAC operation to the hash_result[] is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING type.
@@ -819,7 +892,7 @@ session is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and in
\paragraph{Steps of Operation}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation / Steps of Operation}
-\subparagraph{Step1: Create session}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation / Steps of Operation / Step1: Create session}
+\subparagraph{Step1: Create session}\label{sec:Device Types / Crypto Device / Device Operation / Symmetric algorithms Operation / Steps of Operation / Step1: Create session if using session mode}
\begin{enumerate}
\item The driver specifies information in struct virtio_crypto_op_ctrl_req, including the algorithm name, key, keylen etc;
@@ -848,7 +921,7 @@ session is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and in
\item The device sets the \field{status} in struct virtio_crypto_inhdr;
\item The device updates and flushes the Used Ring to return the cryptographic results to the driver;
\item The device notifies the driver (Or the driver actively polls the dataq's Used Ring);
-\item The driver saves the cryptographic result.
+\item The driver saves the cryptographic results.
\end{enumerate}
\begin{note}
@@ -862,6 +935,15 @@ session is of the VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING operation type and in
\begin{lstlisting}
struct virtio_crypto_aead_para {
+ struct {
+ /* See VIRTIO_CRYPTO_AEAD_* above */
+ le32 algo;
+ /* length of key */
+ le32 key_len;
+ /* encrypt or decrypt, See above VIRTIO_CRYPTO_OP_* */
+ le32 op;
+ } sess_para;
+
/*
* Byte Length of valid IV data.
*
@@ -871,20 +953,21 @@ struct virtio_crypto_aead_para {
* range 7 to 13 inclusive.
*/
le32 iv_len;
+ /* Authentication tag length */
+ le32 tag_len;
/* length of additional auth data */
le32 aad_len;
/* length of source data */
le32 src_data_len;
- /* length of dst data */
+ /* length of dst data, this should be at least src_data_len + tag_len */
le32 dst_data_len;
- /* Length of the hash result */
- le32 hash_result_len;
- le32 reserver;
};
struct virtio_crypto_aead_data_req {
/* Device-readable part */
struct virtio_crypto_aead_para para;
+ /* The cipher key */
+ u8 key[key_len];
/*
* Initialization Vector data.
*
@@ -906,10 +989,9 @@ struct virtio_crypto_aead_data_req {
u8 aad[aad_len];
/* Device-writable part */
- /* Destination data */
+ /* Pointer to output data */
u8 dst_data[dst_data_len];
- /* Hash result data */
- u8 hash_result[hash_result_len];
+
struct virtio_crypto_inhdr inhdr;
};
\end{lstlisting}
@@ -918,10 +1000,9 @@ Each data request uses virtio_crypto_aead_data_req structure to store informatio
used to run the AEAD operations.
The information includes the hash parameters stored by \field{para}, output data and input data.
-In the first virtio_crypto_aead_para structure, \field{iv_len} specifies the length of the initialization vector.
+In the first virtio_crypto_aead_para structure, \field{iv_len} specifies the length of the initialization vector. \field{tag_len} specifies the length of the authentication tag;
\field{aad_len} specifies the length of additional authentication data, \field{src_data_len} specifies the
-length of the source data; \field{dst_data_len} specifies the length of the destination data.
-The output data here includes the IV data and source data, and the input data includes the destination data used to save the results of the CIPHER operations.
+length of the source data; \field{dst_data_len} specifies the length of the destination data, which is at least \field{src_data_len} + \field{tag_len}.
The output data here includes the IV/Counter data, source data and additional authenticated data if exists.
The input data includes both destination data used to save the results of the AEAD operations.
@@ -930,9 +1011,11 @@ The input data includes both destination data used to save the results of the AE
\drivernormative{\paragraph}{AEAD Service Operation}{Device Types / Crypto Device / Device Operation / AEAD Service Operation}
\begin{itemize*}
-\item The driver MUST set the \field{session_id} in struct virtio_crypto_op_header to a valid value which assigned by the device when a session is created.
+\item If the VIRTIO_CRYPTO_F_AEAD_SESSION_MODE feature bit is negotiated and the driver uses the session mode, then the driver MUST set the \field{session_id} in struct virtio_crypto_op_header
+ to a valid value which assigned by the device when a session is created and MUST set \field{flag} field to VIRTIO_CRYPTO_FLAG_SESSION_MODE.
+\item If the VIRTIO_CRYPTO_F_AEAD_SESSION_MODE feature bit is not negotiated or the driver doesn't use the session mode, then the driver MUST set \field{flag} field in struct virtio_crypto_op_header
+ to VIRTIO_CRYPTO_FLAG_SESSION_NONE_MODE and MUST set fields in struct virtio_crypto_aead_para.sess_para.
\item The driver MUST set \field{opcode} in struct virtio_crypto_op_header to VIRTIO_CRYPTO_AEAD_ENCRYPT or VIRTIO_CRYPTO_AEAD_DECRYPT.
-\item The driver MUST set the \field{queue_id} field to show used dataq in struct virtio_crypto_op_header.
\end{itemize*}
\devicenormative{\paragraph}{AEAD Service Operation}{Device Types / Crypto Device / Device Operation / AEAD Service Operation}
@@ -940,7 +1023,7 @@ The input data includes both destination data used to save the results of the AE
\begin{itemize*}
\item The device MUST parse the virtio_crypto_aead_data_req based on the \field{opcode} in general header.
\item The device MUST copy the result of cryptographic operation to the dst_data[].
-\item The device MUST copy the hash result to the hash_result[].
+\item The device MUST copy the authentication tag to the dst_data[] offset the cipher result.
\item The device MUST set the \field{status} field in struct virtio_crypto_inhdr to one of the values of enum VIRITO_CRYPTO_STATUS.
\item When the \field{opcode} is VIRTIO_CRYPTO_AEAD_DECRYPT, the device MUST verify and return the verification result to the driver, and if the verification result is incorrect, VIRTIO_CRYPTO_BADMSG (bad message) MUST be returned to the driver.
\end{itemize*}
\ No newline at end of file
Regards,
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Wednesday, January 04, 2017 6:03 PM
> To: qemu-devel@nongnu.org; virtio-dev@lists.oasis-open.org
> Cc: Luonengjun; mst@redhat.com; cornelia.huck@de.ibm.com;
> stefanha@redhat.com; denglingli@chinamobile.com; Jani Kokkonen;
> Ola.Liljedahl@arm.com; Varun.Sethi@freescale.com; xin.zeng@intel.com;
> brian.a.keating@intel.com; liang.j.ma@intel.com; john.griffin@intel.com;
> Huangweidong (C); mike.caraman@nxp.com; agraf@suse.de; Claudio Fontana;
> Zhoujian (jay, Euler); nmorey@kalray.eu; vincent.jardin@6wind.com; Wubin (H);
> Shiqing Fan; arei.gonglei@hotmail.com; pasic@linux.vnet.ibm.com; Gonglei
> (Arei)
> Subject: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
>
> Changes since v14:
> - drop VIRTIO_CRYPTO_S_STARTED status [Halil & Cornelia]
> - correct a sentence about dataqueue and controlq in the first paragraph.
> [Halil]
> - change a MAY to MUST about max_dataqueues. [Halil]
> - add non-session mode support
> 1) add four features for different crypto services to identify wheather
> support session mode.
> 2) extend virtio_crypto_*_para structures, for example, add the content of
> struct virtio_crypto_cipher_session_para into struct
> virtio_crypto_cipher_para.
> 3) use the flag property of struct virtio_crypto_op_header to identify the
> type of crypto request. Aka Is it a session-based or non-session request
>
> For pervious versions of virtio crypto spec, Pls see:
>
> [v14]:
> https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02212.html
>
> [v13]:
> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg07348.html
>
> For more information, please see:
> http://qemu-project.org/Features/VirtioCrypto
>
> Please help to review, thanks.
>
> Gonglei (2):
> virtio-crypto: Add virtio crypto device specification
> virtio-crypto: Add conformance clauses
>
> conformance.tex | 30 ++
> content.tex | 2 +
> virtio-crypto.tex | 1029
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1061 insertions(+)
> create mode 100644 virtio-crypto.tex
>
> --
> 1.7.12.4
>
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-04 10:10 ` [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei (Arei)
@ 2017-01-12 11:58 ` Halil Pasic
2017-01-12 12:26 ` [Qemu-devel] [virtio-dev] " Gonglei (Arei)
0 siblings, 1 reply; 18+ messages in thread
From: Halil Pasic @ 2017-01-12 11:58 UTC (permalink / raw)
To: Gonglei (Arei), qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org
Cc: Huangweidong (C), mst@redhat.com, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, agraf@suse.de, nmorey@kalray.eu,
vincent.jardin@6wind.com, Ola.Liljedahl@arm.com, Luonengjun,
xin.zeng@intel.com, liang.j.ma@intel.com, stefanha@redhat.com,
Shiqing Fan, Jani Kokkonen, brian.a.keating@intel.com,
Claudio Fontana, mike.caraman@nxp.com, Wubin (H)
On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> Hi all,
>
> I attach the diff files between v14 and v15 for better review.
>
Hi,
only had a quick look. Will try to come back to this later.
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> index 9f7faf0..884ee95 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -2,8 +2,8 @@
>
> The virtio crypto device is a virtual cryptography device as well as a kind of
> virtual hardware accelerator for virtual machines. The encryption and
> -decryption requests are placed in the data queue and are ultimately handled by the
> -backend crypto accelerators. The second queue is the control queue used to create
> +decryption requests are placed in any of the data active queues and are ultimately handled by the
s/data active/active data/
> +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.
[..]
> ===============The below diff shows the changes of add non-session mode support:
>
> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> index 884ee95..44819f9 100644
> --- a/virtio-crypto.tex
> +++ b/virtio-crypto.tex
> @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
>
> \subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature bits}
>
> -None currently defined.
> +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is available for CIPHER service.
> +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available for HASH service.
> +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available for MAC service.
> +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available for AEAD service.
>
> \subsection{Device configuration layout}\label{sec:Device Types / Crypto Device / Device configuration layout}
>
> @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific parameters, output data is the
> data that should be utilized in operations, and input data is equal to
> "operation result + result data".
>
> +The device can support both session mode (See \ref{sec:Device Types / Crypto Device / Device Operation / Control Virtqueue / Session operation}) and non-session mode, for example,
> +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the driver can use session mode for CIPHER service, otherwise it can only use non-session mode.
> +
As far as I understand you are adding non-session mode to the mix but
providing feature bits for session mode. Would this render the the current
implementation non-compliant?
Halil
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-12 11:58 ` Halil Pasic
@ 2017-01-12 12:26 ` Gonglei (Arei)
2017-01-12 19:45 ` Michael S. Tsirkin
0 siblings, 1 reply; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-12 12:26 UTC (permalink / raw)
To: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org
Cc: Huangweidong (C), mst@redhat.com, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, agraf@suse.de, nmorey@kalray.eu,
vincent.jardin@6wind.com, Ola.Liljedahl@arm.com, Luonengjun,
xin.zeng@intel.com, liang.j.ma@intel.com, stefanha@redhat.com,
Shiqing Fan, Jani Kokkonen, brian.a.keating@intel.com,
Claudio Fontana, mike.caraman@nxp.com, Wubin (H)
Hi,
>
> On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > Hi all,
> >
> > I attach the diff files between v14 and v15 for better review.
> >
> Hi,
>
> only had a quick look. Will try to come back to this later.
>
That's cool.
> > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > index 9f7faf0..884ee95 100644
> > --- a/virtio-crypto.tex
> > +++ b/virtio-crypto.tex
> > @@ -2,8 +2,8 @@
> >
> > The virtio crypto device is a virtual cryptography device as well as a kind of
> > virtual hardware accelerator for virtual machines. The encryption and
> > -decryption requests are placed in the data queue and are ultimately handled
> by the
> > -backend crypto accelerators. The second queue is the control queue used to
> create
> > +decryption requests are placed in any of the data active queues and are
> ultimately handled by the
> s/data active/active data/
> > +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.
>
> [..]
>
> > ===============The below diff shows the changes of add non-session mode
> support:
> >
> > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > index 884ee95..44819f9 100644
> > --- a/virtio-crypto.tex
> > +++ b/virtio-crypto.tex
> > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> >
> > \subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature
> bits}
> >
> > -None currently defined.
> > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is available
> for CIPHER service.
> > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available for
> HASH service.
> > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available for
> MAC service.
> > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available for
> AEAD service.
> >
> > \subsection{Device configuration layout}\label{sec:Device Types / Crypto
> Device / Device configuration layout}
> >
> > @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific
> parameters, output data is the
> > data that should be utilized in operations, and input data is equal to
> > "operation result + result data".
> >
> > +The device can support both session mode (See \ref{sec:Device Types /
> Crypto Device / Device Operation / Control Virtqueue / Session operation}) and
> non-session mode, for example,
> > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the driver
> can use session mode for CIPHER service, otherwise it can only use non-session
> mode.
> > +
>
> As far as I understand you are adding non-session mode to the mix but
> providing feature bits for session mode. Would this render the the current
> implementation non-compliant?
>
You are right, shall we use feature bits for non-session mode for compliancy?
Or because the spec is on the fly, and some structures in the virtio_crypto.h need to
be modified, can we keep the compliancy completely?
Thanks,
-Gonglei
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-12 12:26 ` [Qemu-devel] [virtio-dev] " Gonglei (Arei)
@ 2017-01-12 19:45 ` Michael S. Tsirkin
2017-01-13 2:54 ` Gonglei (Arei)
0 siblings, 1 reply; 18+ messages in thread
From: Michael S. Tsirkin @ 2017-01-12 19:45 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org, Huangweidong (C),
john.griffin@intel.com, cornelia.huck@de.ibm.com,
Zhoujian (jay, Euler), Varun.Sethi@freescale.com,
denglingli@chinamobile.com, arei.gonglei@hotmail.com,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
> Hi,
>
>
> >
> > On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > > Hi all,
> > >
> > > I attach the diff files between v14 and v15 for better review.
> > >
> > Hi,
> >
> > only had a quick look. Will try to come back to this later.
> >
> That's cool.
>
> > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > index 9f7faf0..884ee95 100644
> > > --- a/virtio-crypto.tex
> > > +++ b/virtio-crypto.tex
> > > @@ -2,8 +2,8 @@
> > >
> > > The virtio crypto device is a virtual cryptography device as well as a kind of
> > > virtual hardware accelerator for virtual machines. The encryption and
> > > -decryption requests are placed in the data queue and are ultimately handled
> > by the
> > > -backend crypto accelerators. The second queue is the control queue used to
> > create
> > > +decryption requests are placed in any of the data active queues and are
> > ultimately handled by the
> > s/data active/active data/
> > > +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.
> >
> > [..]
> >
> > > ===============The below diff shows the changes of add non-session mode
> > support:
> > >
> > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > index 884ee95..44819f9 100644
> > > --- a/virtio-crypto.tex
> > > +++ b/virtio-crypto.tex
> > > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> > >
> > > \subsection{Feature bits}\label{sec:Device Types / Crypto Device / Feature
> > bits}
> > >
> > > -None currently defined.
> > > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is available
> > for CIPHER service.
> > > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available for
> > HASH service.
> > > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available for
> > MAC service.
> > > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available for
> > AEAD service.
> > >
> > > \subsection{Device configuration layout}\label{sec:Device Types / Crypto
> > Device / Device configuration layout}
> > >
> > > @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific
> > parameters, output data is the
> > > data that should be utilized in operations, and input data is equal to
> > > "operation result + result data".
> > >
> > > +The device can support both session mode (See \ref{sec:Device Types /
> > Crypto Device / Device Operation / Control Virtqueue / Session operation}) and
> > non-session mode, for example,
> > > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the driver
> > can use session mode for CIPHER service, otherwise it can only use non-session
> > mode.
> > > +
> >
> > As far as I understand you are adding non-session mode to the mix but
> > providing feature bits for session mode. Would this render the the current
> > implementation non-compliant?
> >
> You are right, shall we use feature bits for non-session mode for compliancy?
> Or because the spec is on the fly, and some structures in the virtio_crypto.h need to
> be modified, can we keep the compliancy completely?
>
> Thanks,
> -Gonglei
Since there's a linux driver upstream you must at least
keep compatibility with that.
--
MST
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-12 19:45 ` Michael S. Tsirkin
@ 2017-01-13 2:54 ` Gonglei (Arei)
2017-01-13 16:02 ` Michael S. Tsirkin
0 siblings, 1 reply; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-13 2:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org, Huangweidong (C),
john.griffin@intel.com, cornelia.huck@de.ibm.com,
Zhoujian (jay, Euler), Varun.Sethi@freescale.com,
denglingli@chinamobile.com, arei.gonglei@hotmail.com,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
>
> On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
> > Hi,
> >
> >
> > >
> > > On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > > > Hi all,
> > > >
> > > > I attach the diff files between v14 and v15 for better review.
> > > >
> > > Hi,
> > >
> > > only had a quick look. Will try to come back to this later.
> > >
> > That's cool.
> >
> > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > index 9f7faf0..884ee95 100644
> > > > --- a/virtio-crypto.tex
> > > > +++ b/virtio-crypto.tex
> > > > @@ -2,8 +2,8 @@
> > > >
> > > > The virtio crypto device is a virtual cryptography device as well as a kind
> of
> > > > virtual hardware accelerator for virtual machines. The encryption and
> > > > -decryption requests are placed in the data queue and are ultimately
> handled
> > > by the
> > > > -backend crypto accelerators. The second queue is the control queue used
> to
> > > create
> > > > +decryption requests are placed in any of the data active queues and are
> > > ultimately handled by the
> > > s/data active/active data/
> > > > +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.
> > >
> > > [..]
> > >
> > > > ===============The below diff shows the changes of add non-session
> mode
> > > support:
> > > >
> > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > index 884ee95..44819f9 100644
> > > > --- a/virtio-crypto.tex
> > > > +++ b/virtio-crypto.tex
> > > > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> > > >
> > > > \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> Feature
> > > bits}
> > > >
> > > > -None currently defined.
> > > > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
> available
> > > for CIPHER service.
> > > > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available
> for
> > > HASH service.
> > > > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available
> for
> > > MAC service.
> > > > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available
> for
> > > AEAD service.
> > > >
> > > > \subsection{Device configuration layout}\label{sec:Device Types /
> Crypto
> > > Device / Device configuration layout}
> > > >
> > > > @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific
> > > parameters, output data is the
> > > > data that should be utilized in operations, and input data is equal to
> > > > "operation result + result data".
> > > >
> > > > +The device can support both session mode (See \ref{sec:Device Types /
> > > Crypto Device / Device Operation / Control Virtqueue / Session operation})
> and
> > > non-session mode, for example,
> > > > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the
> driver
> > > can use session mode for CIPHER service, otherwise it can only use
> non-session
> > > mode.
> > > > +
> > >
> > > As far as I understand you are adding non-session mode to the mix but
> > > providing feature bits for session mode. Would this render the the current
> > > implementation non-compliant?
> > >
> > You are right, shall we use feature bits for non-session mode for compliancy?
> > Or because the spec is on the fly, and some structures in the virtio_crypto.h
> need to
> > be modified, can we keep the compliancy completely?
> >
> > Thanks,
> > -Gonglei
>
> Since there's a linux driver upstream you must at least
> keep compatibility with that.
>
Sure. We use feature bits for non-session mode then.
For structures modification, do we need to do some specific
actions for compatibility? Take CIPHER service as an example:
The present structure:
struct virtio_crypto_cipher_para {
/*
* Byte Length of valid IV/Counter data pointed to by the below iv data.
*
* For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
* SNOW3G in UEA2 mode, this is the length of the IV (which
* must be the same as the block length of the cipher).
* For block ciphers in CTR mode, this is the length of the counter
* (which must be the same as the block length of the cipher).
*/
le32 iv_len;
/* length of source data */
le32 src_data_len;
/* length of destination data */
le32 dst_data_len;
};
The future structure if supporting non-session based operations:
struct virtio_crypto_cipher_para {
struct {
/* See VIRTIO_CRYPTO_CIPHER* above */
le32 algo;
/* length of key */
le32 keylen;
/* See VIRTIO_CRYPTO_OP_* above */
le32 op;
} sess_para;
/*
* Byte Length of valid IV/Counter data pointed to by the below iv data.
*
* For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
* SNOW3G in UEA2 mode, this is the length of the IV (which
* must be the same as the block length of the cipher).
* For block ciphers in CTR mode, this is the length of the counter
* (which must be the same as the block length of the cipher).
*/
le32 iv_len;
/* length of source data */
le32 src_data_len;
/* length of destination data */
le32 dst_data_len;
};
Thanks,
-Gonglei
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-13 2:54 ` Gonglei (Arei)
@ 2017-01-13 16:02 ` Michael S. Tsirkin
2017-01-14 1:20 ` Gonglei (Arei)
2017-01-16 12:43 ` Gonglei (Arei)
0 siblings, 2 replies; 18+ messages in thread
From: Michael S. Tsirkin @ 2017-01-13 16:02 UTC (permalink / raw)
To: Gonglei (Arei)
Cc: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org, Huangweidong (C),
john.griffin@intel.com, cornelia.huck@de.ibm.com,
Zhoujian (jay, Euler), Varun.Sethi@freescale.com,
denglingli@chinamobile.com, arei.gonglei@hotmail.com,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
On Fri, Jan 13, 2017 at 02:54:29AM +0000, Gonglei (Arei) wrote:
>
> >
> > On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
> > > Hi,
> > >
> > >
> > > >
> > > > On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > > > > Hi all,
> > > > >
> > > > > I attach the diff files between v14 and v15 for better review.
> > > > >
> > > > Hi,
> > > >
> > > > only had a quick look. Will try to come back to this later.
> > > >
> > > That's cool.
> > >
> > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > index 9f7faf0..884ee95 100644
> > > > > --- a/virtio-crypto.tex
> > > > > +++ b/virtio-crypto.tex
> > > > > @@ -2,8 +2,8 @@
> > > > >
> > > > > The virtio crypto device is a virtual cryptography device as well as a kind
> > of
> > > > > virtual hardware accelerator for virtual machines. The encryption and
> > > > > -decryption requests are placed in the data queue and are ultimately
> > handled
> > > > by the
> > > > > -backend crypto accelerators. The second queue is the control queue used
> > to
> > > > create
> > > > > +decryption requests are placed in any of the data active queues and are
> > > > ultimately handled by the
> > > > s/data active/active data/
> > > > > +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.
> > > >
> > > > [..]
> > > >
> > > > > ===============The below diff shows the changes of add non-session
> > mode
> > > > support:
> > > > >
> > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > index 884ee95..44819f9 100644
> > > > > --- a/virtio-crypto.tex
> > > > > +++ b/virtio-crypto.tex
> > > > > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> > > > >
> > > > > \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> > Feature
> > > > bits}
> > > > >
> > > > > -None currently defined.
> > > > > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
> > available
> > > > for CIPHER service.
> > > > > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is available
> > for
> > > > HASH service.
> > > > > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is available
> > for
> > > > MAC service.
> > > > > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is available
> > for
> > > > AEAD service.
> > > > >
> > > > > \subsection{Device configuration layout}\label{sec:Device Types /
> > Crypto
> > > > Device / Device configuration layout}
> > > > >
> > > > > @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific
> > > > parameters, output data is the
> > > > > data that should be utilized in operations, and input data is equal to
> > > > > "operation result + result data".
> > > > >
> > > > > +The device can support both session mode (See \ref{sec:Device Types /
> > > > Crypto Device / Device Operation / Control Virtqueue / Session operation})
> > and
> > > > non-session mode, for example,
> > > > > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated, the
> > driver
> > > > can use session mode for CIPHER service, otherwise it can only use
> > non-session
> > > > mode.
> > > > > +
> > > >
> > > > As far as I understand you are adding non-session mode to the mix but
> > > > providing feature bits for session mode. Would this render the the current
> > > > implementation non-compliant?
> > > >
> > > You are right, shall we use feature bits for non-session mode for compliancy?
> > > Or because the spec is on the fly, and some structures in the virtio_crypto.h
> > need to
> > > be modified, can we keep the compliancy completely?
> > >
> > > Thanks,
> > > -Gonglei
> >
> > Since there's a linux driver upstream you must at least
> > keep compatibility with that.
> >
> Sure. We use feature bits for non-session mode then.
> For structures modification, do we need to do some specific
> actions for compatibility? Take CIPHER service as an example:
>
> The present structure:
>
> struct virtio_crypto_cipher_para {
> /*
> * Byte Length of valid IV/Counter data pointed to by the below iv data.
> *
> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
> * SNOW3G in UEA2 mode, this is the length of the IV (which
> * must be the same as the block length of the cipher).
> * For block ciphers in CTR mode, this is the length of the counter
> * (which must be the same as the block length of the cipher).
> */
> le32 iv_len;
> /* length of source data */
> le32 src_data_len;
> /* length of destination data */
> le32 dst_data_len;
> };
>
> The future structure if supporting non-session based operations:
>
> struct virtio_crypto_cipher_para {
> struct {
> /* See VIRTIO_CRYPTO_CIPHER* above */
> le32 algo;
> /* length of key */
> le32 keylen;
>
> /* See VIRTIO_CRYPTO_OP_* above */
> le32 op;
> } sess_para;
>
> /*
> * Byte Length of valid IV/Counter data pointed to by the below iv data.
> *
> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
> * SNOW3G in UEA2 mode, this is the length of the IV (which
> * must be the same as the block length of the cipher).
> * For block ciphers in CTR mode, this is the length of the counter
> * (which must be the same as the block length of the cipher).
> */
> le32 iv_len;
> /* length of source data */
> le32 src_data_len;
> /* length of destination data */
> le32 dst_data_len;
> };
>
> Thanks,
> -Gonglei
So you will have to maintain both structures for when non-session based
feature is and aren't present. You will have to give them different
names, too.
--
MST
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-13 16:02 ` Michael S. Tsirkin
@ 2017-01-14 1:20 ` Gonglei (Arei)
2017-01-16 12:43 ` Gonglei (Arei)
1 sibling, 0 replies; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-14 1:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org, Huangweidong (C),
john.griffin@intel.com, cornelia.huck@de.ibm.com,
Zhoujian (jay, Euler), Varun.Sethi@freescale.com,
denglingli@chinamobile.com, arei.gonglei@hotmail.com,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
>
> On Fri, Jan 13, 2017 at 02:54:29AM +0000, Gonglei (Arei) wrote:
> >
> > >
> > > On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
> > > > Hi,
> > > >
> > > >
> > > > >
> > > > > On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I attach the diff files between v14 and v15 for better review.
> > > > > >
> > > > > Hi,
> > > > >
> > > > > only had a quick look. Will try to come back to this later.
> > > > >
> > > > That's cool.
> > > >
> > > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > > index 9f7faf0..884ee95 100644
> > > > > > --- a/virtio-crypto.tex
> > > > > > +++ b/virtio-crypto.tex
> > > > > > @@ -2,8 +2,8 @@
> > > > > >
> > > > > > The virtio crypto device is a virtual cryptography device as well as a
> kind
> > > of
> > > > > > virtual hardware accelerator for virtual machines. The encryption
> and
> > > > > > -decryption requests are placed in the data queue and are ultimately
> > > handled
> > > > > by the
> > > > > > -backend crypto accelerators. The second queue is the control queue
> used
> > > to
> > > > > create
> > > > > > +decryption requests are placed in any of the data active queues and
> are
> > > > > ultimately handled by the
> > > > > s/data active/active data/
> > > > > > +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.
> > > > >
> > > > > [..]
> > > > >
> > > > > > ===============The below diff shows the changes of add
> non-session
> > > mode
> > > > > support:
> > > > > >
> > > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > > index 884ee95..44819f9 100644
> > > > > > --- a/virtio-crypto.tex
> > > > > > +++ b/virtio-crypto.tex
> > > > > > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> > > > > >
> > > > > > \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> > > Feature
> > > > > bits}
> > > > > >
> > > > > > -None currently defined.
> > > > > > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
> > > available
> > > > > for CIPHER service.
> > > > > > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is
> available
> > > for
> > > > > HASH service.
> > > > > > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is
> available
> > > for
> > > > > MAC service.
> > > > > > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is
> available
> > > for
> > > > > AEAD service.
> > > > > >
> > > > > > \subsection{Device configuration layout}\label{sec:Device Types /
> > > Crypto
> > > > > Device / Device configuration layout}
> > > > > >
> > > > > > @@ -208,6 +211,9 @@ Operation parameters are algorithm-specific
> > > > > parameters, output data is the
> > > > > > data that should be utilized in operations, and input data is equal to
> > > > > > "operation result + result data".
> > > > > >
> > > > > > +The device can support both session mode (See \ref{sec:Device Types
> /
> > > > > Crypto Device / Device Operation / Control Virtqueue / Session
> operation})
> > > and
> > > > > non-session mode, for example,
> > > > > > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated,
> the
> > > driver
> > > > > can use session mode for CIPHER service, otherwise it can only use
> > > non-session
> > > > > mode.
> > > > > > +
> > > > >
> > > > > As far as I understand you are adding non-session mode to the mix but
> > > > > providing feature bits for session mode. Would this render the the
> current
> > > > > implementation non-compliant?
> > > > >
> > > > You are right, shall we use feature bits for non-session mode for
> compliancy?
> > > > Or because the spec is on the fly, and some structures in the
> virtio_crypto.h
> > > need to
> > > > be modified, can we keep the compliancy completely?
> > > >
> > > > Thanks,
> > > > -Gonglei
> > >
> > > Since there's a linux driver upstream you must at least
> > > keep compatibility with that.
> > >
> > Sure. We use feature bits for non-session mode then.
> > For structures modification, do we need to do some specific
> > actions for compatibility? Take CIPHER service as an example:
> >
> > The present structure:
> >
> > struct virtio_crypto_cipher_para {
> > /*
> > * Byte Length of valid IV/Counter data pointed to by the below iv data.
> > *
> > * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
> > * SNOW3G in UEA2 mode, this is the length of the IV (which
> > * must be the same as the block length of the cipher).
> > * For block ciphers in CTR mode, this is the length of the counter
> > * (which must be the same as the block length of the cipher).
> > */
> > le32 iv_len;
> > /* length of source data */
> > le32 src_data_len;
> > /* length of destination data */
> > le32 dst_data_len;
> > };
> >
> > The future structure if supporting non-session based operations:
> >
> > struct virtio_crypto_cipher_para {
> > struct {
> > /* See VIRTIO_CRYPTO_CIPHER* above */
> > le32 algo;
> > /* length of key */
> > le32 keylen;
> >
> > /* See VIRTIO_CRYPTO_OP_* above */
> > le32 op;
> > } sess_para;
> >
> > /*
> > * Byte Length of valid IV/Counter data pointed to by the below iv data.
> > *
> > * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or for
> > * SNOW3G in UEA2 mode, this is the length of the IV (which
> > * must be the same as the block length of the cipher).
> > * For block ciphers in CTR mode, this is the length of the counter
> > * (which must be the same as the block length of the cipher).
> > */
> > le32 iv_len;
> > /* length of source data */
> > le32 src_data_len;
> > /* length of destination data */
> > le32 dst_data_len;
> > };
> >
> > Thanks,
> > -Gonglei
>
> So you will have to maintain both structures for when non-session based
> feature is and aren't present. You will have to give them different
> names, too.
>
OK, I get your point. :)
Thanks,
-Gonglei
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-13 16:02 ` Michael S. Tsirkin
2017-01-14 1:20 ` Gonglei (Arei)
@ 2017-01-16 12:43 ` Gonglei (Arei)
2017-01-16 13:58 ` Halil Pasic
1 sibling, 1 reply; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-16 12:43 UTC (permalink / raw)
To: Gonglei (Arei), Michael S. Tsirkin
Cc: Halil Pasic, qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org, Huangweidong (C),
john.griffin@intel.com, cornelia.huck@de.ibm.com,
Zhoujian (jay, Euler), Varun.Sethi@freescale.com,
denglingli@chinamobile.com, arei.gonglei@hotmail.com,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
Hi Michael and others,
I'd like to redefine struct virtio_crypto_op_data_req is as below:
struct virtio_crypto_op_data_req {
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;
__u8 padding[72];
} u;
};
The length of union in the structure will be changed, which from current 48 byte to 72 byte.
We couldn't redefine a structure named virtio_crypto_op_data_req_non_sess,
Because the feature bits are for crypto services, not for the wrapper packet request.
It's impossible to mixed use struct virtio_crypto_op_data_req and
struct named virtio_crypto_op_data_req_non_sess for one data virtqueue.
For driver compabity, I can submit patches for linux dirver and Qemu to change the length
of struct virtio_crypto_op_data_req.u
Is the approach available?
Thanks,
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Saturday, January 14, 2017 9:21 AM
> To: 'Michael S. Tsirkin'
> Cc: Halil Pasic; qemu-devel@nongnu.org; virtio-dev@lists.oasis-open.org;
> Huangweidong (C); john.griffin@intel.com; cornelia.huck@de.ibm.com;
> Zhoujian (jay, Euler); Varun.Sethi@freescale.com; denglingli@chinamobile.com;
> arei.gonglei@hotmail.com; agraf@suse.de; nmorey@kalray.eu;
> vincent.jardin@6wind.com; Ola.Liljedahl@arm.com; Luonengjun;
> xin.zeng@intel.com; liang.j.ma@intel.com; stefanha@redhat.com; Shiqing Fan;
> Jani Kokkonen; brian.a.keating@intel.com; Claudio Fontana;
> mike.caraman@nxp.com; Wubin (H)
> Subject: RE: [virtio-dev] Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio
> crypto device specification
>
> >
> > On Fri, Jan 13, 2017 at 02:54:29AM +0000, Gonglei (Arei) wrote:
> > >
> > > >
> > > > On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
> > > > > Hi,
> > > > >
> > > > >
> > > > > >
> > > > > > On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I attach the diff files between v14 and v15 for better review.
> > > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > only had a quick look. Will try to come back to this later.
> > > > > >
> > > > > That's cool.
> > > > >
> > > > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > > > index 9f7faf0..884ee95 100644
> > > > > > > --- a/virtio-crypto.tex
> > > > > > > +++ b/virtio-crypto.tex
> > > > > > > @@ -2,8 +2,8 @@
> > > > > > >
> > > > > > > The virtio crypto device is a virtual cryptography device as well as a
> > kind
> > > > of
> > > > > > > virtual hardware accelerator for virtual machines. The encryption
> > and
> > > > > > > -decryption requests are placed in the data queue and are ultimately
> > > > handled
> > > > > > by the
> > > > > > > -backend crypto accelerators. The second queue is the control queue
> > used
> > > > to
> > > > > > create
> > > > > > > +decryption requests are placed in any of the data active queues and
> > are
> > > > > > ultimately handled by the
> > > > > > s/data active/active data/
> > > > > > > +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.
> > > > > >
> > > > > > [..]
> > > > > >
> > > > > > > ===============The below diff shows the changes of add
> > non-session
> > > > mode
> > > > > > support:
> > > > > > >
> > > > > > > diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> > > > > > > index 884ee95..44819f9 100644
> > > > > > > --- a/virtio-crypto.tex
> > > > > > > +++ b/virtio-crypto.tex
> > > > > > > @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> > > > > > >
> > > > > > > \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> > > > Feature
> > > > > > bits}
> > > > > > >
> > > > > > > -None currently defined.
> > > > > > > +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
> > > > available
> > > > > > for CIPHER service.
> > > > > > > +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is
> > available
> > > > for
> > > > > > HASH service.
> > > > > > > +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is
> > available
> > > > for
> > > > > > MAC service.
> > > > > > > +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is
> > available
> > > > for
> > > > > > AEAD service.
> > > > > > >
> > > > > > > \subsection{Device configuration layout}\label{sec:Device Types /
> > > > Crypto
> > > > > > Device / Device configuration layout}
> > > > > > >
> > > > > > > @@ -208,6 +211,9 @@ Operation parameters are
> algorithm-specific
> > > > > > parameters, output data is the
> > > > > > > data that should be utilized in operations, and input data is equal
> to
> > > > > > > "operation result + result data".
> > > > > > >
> > > > > > > +The device can support both session mode (See \ref{sec:Device
> Types
> > /
> > > > > > Crypto Device / Device Operation / Control Virtqueue / Session
> > operation})
> > > > and
> > > > > > non-session mode, for example,
> > > > > > > +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated,
> > the
> > > > driver
> > > > > > can use session mode for CIPHER service, otherwise it can only use
> > > > non-session
> > > > > > mode.
> > > > > > > +
> > > > > >
> > > > > > As far as I understand you are adding non-session mode to the mix but
> > > > > > providing feature bits for session mode. Would this render the the
> > current
> > > > > > implementation non-compliant?
> > > > > >
> > > > > You are right, shall we use feature bits for non-session mode for
> > compliancy?
> > > > > Or because the spec is on the fly, and some structures in the
> > virtio_crypto.h
> > > > need to
> > > > > be modified, can we keep the compliancy completely?
> > > > >
> > > > > Thanks,
> > > > > -Gonglei
> > > >
> > > > Since there's a linux driver upstream you must at least
> > > > keep compatibility with that.
> > > >
> > > Sure. We use feature bits for non-session mode then.
> > > For structures modification, do we need to do some specific
> > > actions for compatibility? Take CIPHER service as an example:
> > >
> > > The present structure:
> > >
> > > struct virtio_crypto_cipher_para {
> > > /*
> > > * Byte Length of valid IV/Counter data pointed to by the below iv
> data.
> > > *
> > > * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or
> for
> > > * SNOW3G in UEA2 mode, this is the length of the IV (which
> > > * must be the same as the block length of the cipher).
> > > * For block ciphers in CTR mode, this is the length of the counter
> > > * (which must be the same as the block length of the cipher).
> > > */
> > > le32 iv_len;
> > > /* length of source data */
> > > le32 src_data_len;
> > > /* length of destination data */
> > > le32 dst_data_len;
> > > };
> > >
> > > The future structure if supporting non-session based operations:
> > >
> > > struct virtio_crypto_cipher_para {
> > > struct {
> > > /* See VIRTIO_CRYPTO_CIPHER* above */
> > > le32 algo;
> > > /* length of key */
> > > le32 keylen;
> > >
> > > /* See VIRTIO_CRYPTO_OP_* above */
> > > le32 op;
> > > } sess_para;
> > >
> > > /*
> > > * Byte Length of valid IV/Counter data pointed to by the below iv
> data.
> > > *
> > > * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or
> for
> > > * SNOW3G in UEA2 mode, this is the length of the IV (which
> > > * must be the same as the block length of the cipher).
> > > * For block ciphers in CTR mode, this is the length of the counter
> > > * (which must be the same as the block length of the cipher).
> > > */
> > > le32 iv_len;
> > > /* length of source data */
> > > le32 src_data_len;
> > > /* length of destination data */
> > > le32 dst_data_len;
> > > };
> > >
> > > Thanks,
> > > -Gonglei
> >
> > So you will have to maintain both structures for when non-session based
> > feature is and aren't present. You will have to give them different
> > names, too.
> >
> OK, I get your point. :)
>
> Thanks,
> -Gonglei
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-16 12:43 ` Gonglei (Arei)
@ 2017-01-16 13:58 ` Halil Pasic
2017-01-17 2:49 ` Gonglei (Arei)
0 siblings, 1 reply; 18+ messages in thread
From: Halil Pasic @ 2017-01-16 13:58 UTC (permalink / raw)
To: Gonglei (Arei), Michael S. Tsirkin
Cc: Huangweidong (C), qemu-devel@nongnu.org, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, virtio-dev@lists.oasis-open.org,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
On 01/16/2017 01:43 PM, Gonglei (Arei) wrote:
> Hi Michael and others,
>
> I'd like to redefine struct virtio_crypto_op_data_req is as below:
>
> struct virtio_crypto_op_data_req {
> 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;
> __u8 padding[72];
> } u;
> };
>
> The length of union in the structure will be changed, which from current 48 byte to 72 byte.
>
> We couldn't redefine a structure named virtio_crypto_op_data_req_non_sess,
> Because the feature bits are for crypto services, not for the wrapper packet request.
>
You mean virtio_crypto_op_data_req.virtio_crypto_op_header.flags
are conceptually meant for something else and using that field woulb
be misuse?
> It's impossible to mixed use struct virtio_crypto_op_data_req and
> struct named virtio_crypto_op_data_req_non_sess for one data virtqueue.
>
I do not understand what are you trying to say here. I think you
should tell us what is the new feature and how it is guarded.
Would this mean that session or non-session mode will be tied
to the whole device, or to one data-queue. If it's data-queue
level how is it controlled (e.g. control queue)?
I guess virtio_crypto_op_data_req.virtio_crypto_op_header.session_id
would become meaningless in case of non_sess?
> For driver compabity, I can submit patches for linux dirver and Qemu to change the length
> of struct virtio_crypto_op_data_req.u
>
> Is the approach available?
>
In general and AFAIU any new behavior is possible, iff it
is appropriately guarded by some negotiation mechanism and
does not break per-existing code which knows nothing about
the new stuff.
I would not mind seeing a spec re-spin with a proper
proposal for session-less or stateless or whatever mode.
Cheers,
Halil
> Thanks,
> -Gonglei
>
>
>> -----Original Message-----
>> From: Gonglei (Arei)
>> Sent: Saturday, January 14, 2017 9:21 AM
>> To: 'Michael S. Tsirkin'
>> Cc: Halil Pasic; qemu-devel@nongnu.org; virtio-dev@lists.oasis-open.org;
>> Huangweidong (C); john.griffin@intel.com; cornelia.huck@de.ibm.com;
>> Zhoujian (jay, Euler); Varun.Sethi@freescale.com; denglingli@chinamobile.com;
>> arei.gonglei@hotmail.com; agraf@suse.de; nmorey@kalray.eu;
>> vincent.jardin@6wind.com; Ola.Liljedahl@arm.com; Luonengjun;
>> xin.zeng@intel.com; liang.j.ma@intel.com; stefanha@redhat.com; Shiqing Fan;
>> Jani Kokkonen; brian.a.keating@intel.com; Claudio Fontana;
>> mike.caraman@nxp.com; Wubin (H)
>> Subject: RE: [virtio-dev] Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio
>> crypto device specification
>>
>>>
>>> On Fri, Jan 13, 2017 at 02:54:29AM +0000, Gonglei (Arei) wrote:
>>>>
>>>>>
>>>>> On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I attach the diff files between v14 and v15 for better review.
>>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> only had a quick look. Will try to come back to this later.
>>>>>>>
>>>>>> That's cool.
>>>>>>
>>>>>>>> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
>>>>>>>> index 9f7faf0..884ee95 100644
>>>>>>>> --- a/virtio-crypto.tex
>>>>>>>> +++ b/virtio-crypto.tex
>>>>>>>> @@ -2,8 +2,8 @@
>>>>>>>>
>>>>>>>> The virtio crypto device is a virtual cryptography device as well as a
>>> kind
>>>>> of
>>>>>>>> virtual hardware accelerator for virtual machines. The encryption
>>> and
>>>>>>>> -decryption requests are placed in the data queue and are ultimately
>>>>> handled
>>>>>>> by the
>>>>>>>> -backend crypto accelerators. The second queue is the control queue
>>> used
>>>>> to
>>>>>>> create
>>>>>>>> +decryption requests are placed in any of the data active queues and
>>> are
>>>>>>> ultimately handled by the
>>>>>>> s/data active/active data/
>>>>>>>> +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.
>>>>>>>
>>>>>>> [..]
>>>>>>>
>>>>>>>> ===============The below diff shows the changes of add
>>> non-session
>>>>> mode
>>>>>>> support:
>>>>>>>>
>>>>>>>> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
>>>>>>>> index 884ee95..44819f9 100644
>>>>>>>> --- a/virtio-crypto.tex
>>>>>>>> +++ b/virtio-crypto.tex
>>>>>>>> @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
>>>>>>>>
>>>>>>>> \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
>>>>> Feature
>>>>>>> bits}
>>>>>>>>
>>>>>>>> -None currently defined.
>>>>>>>> +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
>>>>> available
>>>>>>> for CIPHER service.
>>>>>>>> +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is
>>> available
>>>>> for
>>>>>>> HASH service.
>>>>>>>> +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is
>>> available
>>>>> for
>>>>>>> MAC service.
>>>>>>>> +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is
>>> available
>>>>> for
>>>>>>> AEAD service.
>>>>>>>>
>>>>>>>> \subsection{Device configuration layout}\label{sec:Device Types /
>>>>> Crypto
>>>>>>> Device / Device configuration layout}
>>>>>>>>
>>>>>>>> @@ -208,6 +211,9 @@ Operation parameters are
>> algorithm-specific
>>>>>>> parameters, output data is the
>>>>>>>> data that should be utilized in operations, and input data is equal
>> to
>>>>>>>> "operation result + result data".
>>>>>>>>
>>>>>>>> +The device can support both session mode (See \ref{sec:Device
>> Types
>>> /
>>>>>>> Crypto Device / Device Operation / Control Virtqueue / Session
>>> operation})
>>>>> and
>>>>>>> non-session mode, for example,
>>>>>>>> +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated,
>>> the
>>>>> driver
>>>>>>> can use session mode for CIPHER service, otherwise it can only use
>>>>> non-session
>>>>>>> mode.
>>>>>>>> +
>>>>>>>
>>>>>>> As far as I understand you are adding non-session mode to the mix but
>>>>>>> providing feature bits for session mode. Would this render the the
>>> current
>>>>>>> implementation non-compliant?
>>>>>>>
>>>>>> You are right, shall we use feature bits for non-session mode for
>>> compliancy?
>>>>>> Or because the spec is on the fly, and some structures in the
>>> virtio_crypto.h
>>>>> need to
>>>>>> be modified, can we keep the compliancy completely?
>>>>>>
>>>>>> Thanks,
>>>>>> -Gonglei
>>>>>
>>>>> Since there's a linux driver upstream you must at least
>>>>> keep compatibility with that.
>>>>>
>>>> Sure. We use feature bits for non-session mode then.
>>>> For structures modification, do we need to do some specific
>>>> actions for compatibility? Take CIPHER service as an example:
>>>>
>>>> The present structure:
>>>>
>>>> struct virtio_crypto_cipher_para {
>>>> /*
>>>> * Byte Length of valid IV/Counter data pointed to by the below iv
>> data.
>>>> *
>>>> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or
>> for
>>>> * SNOW3G in UEA2 mode, this is the length of the IV (which
>>>> * must be the same as the block length of the cipher).
>>>> * For block ciphers in CTR mode, this is the length of the counter
>>>> * (which must be the same as the block length of the cipher).
>>>> */
>>>> le32 iv_len;
>>>> /* length of source data */
>>>> le32 src_data_len;
>>>> /* length of destination data */
>>>> le32 dst_data_len;
>>>> };
>>>>
>>>> The future structure if supporting non-session based operations:
>>>>
>>>> struct virtio_crypto_cipher_para {
>>>> struct {
>>>> /* See VIRTIO_CRYPTO_CIPHER* above */
>>>> le32 algo;
>>>> /* length of key */
>>>> le32 keylen;
>>>>
>>>> /* See VIRTIO_CRYPTO_OP_* above */
>>>> le32 op;
>>>> } sess_para;
>>>>
>>>> /*
>>>> * Byte Length of valid IV/Counter data pointed to by the below iv
>> data.
>>>> *
>>>> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or
>> for
>>>> * SNOW3G in UEA2 mode, this is the length of the IV (which
>>>> * must be the same as the block length of the cipher).
>>>> * For block ciphers in CTR mode, this is the length of the counter
>>>> * (which must be the same as the block length of the cipher).
>>>> */
>>>> le32 iv_len;
>>>> /* length of source data */
>>>> le32 src_data_len;
>>>> /* length of destination data */
>>>> le32 dst_data_len;
>>>> };
>>>>
>>>> Thanks,
>>>> -Gonglei
>>>
>>> So you will have to maintain both structures for when non-session based
>>> feature is and aren't present. You will have to give them different
>>> names, too.
>>>
>> OK, I get your point. :)
>>
>> Thanks,
>> -Gonglei
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-16 13:58 ` Halil Pasic
@ 2017-01-17 2:49 ` Gonglei (Arei)
2017-01-18 17:16 ` [Qemu-devel] [virtio-dev] " Halil Pasic
0 siblings, 1 reply; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-17 2:49 UTC (permalink / raw)
To: Halil Pasic, Michael S. Tsirkin
Cc: Huangweidong (C), qemu-devel@nongnu.org, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, virtio-dev@lists.oasis-open.org,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
Hi Halil,
>
> On 01/16/2017 01:43 PM, Gonglei (Arei) wrote:
> > Hi Michael and others,
> >
> > I'd like to redefine struct virtio_crypto_op_data_req is as below:
> >
> > struct virtio_crypto_op_data_req {
> > 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;
> > __u8 padding[72];
> > } u;
> > };
> >
> > The length of union in the structure will be changed, which from current 48
> byte to 72 byte.
> >
> > We couldn't redefine a structure named
> virtio_crypto_op_data_req_non_sess,
> > Because the feature bits are for crypto services, not for the wrapper packet
> request.
> >
>
> You mean virtio_crypto_op_data_req.virtio_crypto_op_header.flags
> are conceptually meant for something else and using that field woulb
> be misuse?
>
Nope...
>
> > It's impossible to mixed use struct virtio_crypto_op_data_req and
> > struct named virtio_crypto_op_data_req_non_sess for one data virtqueue.
> >
>
> I do not understand what are you trying to say here. I think you
> should tell us what is the new feature and how it is guarded.
>
> Would this mean that session or non-session mode will be tied
> to the whole device, or to one data-queue. If it's data-queue
> level how is it controlled (e.g. control queue)?
>
... I'm so sorry for confusing explanation. Let me try to explain it more clear.
1 ) The first idea: For support non-session mode crypto operations, I introduce 4 feature bits
for different crypto services, they are:
VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is available for CIPHER service.
VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is available for HASH service.
VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is available for MAC service.
VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is available for AEAD service.
but not only one feature bit, something like:
VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
Meanwhile, I define 4 new non-session mode structures for different crypto
services in order to keep compatibility to pre-existing driver.
-*Advantages*:
a) We can support different modes for different crypto services
according to which features are negotiated.
b) The driver can still use the session mode when VIRTIO_CRYPTO_F_*_NON_SESSION_MODE are negotiated,
which is under control by virtio_crypto_op_data_req.virtio_crypto_op_header.flags.
- *Disadvantages*:
The current crypto packets of all
crypto services (CIPHER, HASH, MAC and AEAD) are wrapped in structure
virtio_crypto_op_data_req by an union in the data plane.
It will change the length of the union and break the pre-existing code
if still lay all non-session mode structures in strut virtio_crypto_op_data_req
like this:
struct virtio_crypto_op_data_req {
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;
__u8 padding[72];
} u;
};
So I should submit patches to fix them.
2) Another idea is define a non-session mode structure for strut virtio_crypto_op_data_req.
struct virtio_crypto_op_data_req_non_sess {
struct virtio_crypto_op_header header;
union {
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;
__u8 padding[72];
} u;
};
And keep the pre-existing strut virtio_crypto_op_data_req:
struct virtio_crypto_op_data_req {
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;
__u8 padding[48];
} u;
};
- *Advantages*:
Don't break the pre-existing code.
- *Disadvantages*:
Can't support feature bits for different crypto services,
only the whole device. That means we should only use the below feature
bit:
VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
3) The last idea is define a mixed structure for strut virtio_crypto_op_data_req.
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;
__u8 padding[72];
} u;
};
And keep the pre-existing strut virtio_crypto_op_data_req:
struct virtio_crypto_op_data_req {
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;
__u8 padding[48];
} u;
};
That means we should use below five feature bits:
VIRTIO_CRYPTO_F_ NON_SESSION_MODE (0) non-session mode is available.
VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is available for CIPHER service.
VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is available for HASH service.
VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is available for MAC service.
VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is available for AEAD service.
-*Advantages*:
Both idea 1) and 2).
-*Disadvantages*:
None.
What's your opinion? Thanks a lot!
> I guess virtio_crypto_op_data_req.virtio_crypto_op_header.session_id
> would become meaningless in case of non_sess?
>
That's true.
> > For driver compabity, I can submit patches for linux dirver and Qemu to
> change the length
> > of struct virtio_crypto_op_data_req.u
> >
> > Is the approach available?
> >
>
> In general and AFAIU any new behavior is possible, iff it
> is appropriately guarded by some negotiation mechanism and
> does not break per-existing code which knows nothing about
> the new stuff.
>
> I would not mind seeing a spec re-spin with a proper
> proposal for session-less or stateless or whatever mode.
>
Thanks,
-Gonglei
> Cheers,
> Halil
>
> > Thanks,
> > -Gonglei
> >
> >
> >> -----Original Message-----
> >> From: Gonglei (Arei)
> >> Sent: Saturday, January 14, 2017 9:21 AM
> >> Subject: RE: [virtio-dev] Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto:
> virtio
> >> crypto device specification
> >>
> >>>
> >>> On Fri, Jan 13, 2017 at 02:54:29AM +0000, Gonglei (Arei) wrote:
> >>>>
> >>>>>
> >>>>> On Thu, Jan 12, 2017 at 12:26:24PM +0000, Gonglei (Arei) wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> On 01/04/2017 11:10 AM, Gonglei (Arei) wrote:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> I attach the diff files between v14 and v15 for better review.
> >>>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> only had a quick look. Will try to come back to this later.
> >>>>>>>
> >>>>>> That's cool.
> >>>>>>
> >>>>>>>> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> >>>>>>>> index 9f7faf0..884ee95 100644
> >>>>>>>> --- a/virtio-crypto.tex
> >>>>>>>> +++ b/virtio-crypto.tex
> >>>>>>>> @@ -2,8 +2,8 @@
> >>>>>>>>
> >>>>>>>> The virtio crypto device is a virtual cryptography device as well as a
> >>> kind
> >>>>> of
> >>>>>>>> virtual hardware accelerator for virtual machines. The encryption
> >>> and
> >>>>>>>> -decryption requests are placed in the data queue and are ultimately
> >>>>> handled
> >>>>>>> by the
> >>>>>>>> -backend crypto accelerators. The second queue is the control queue
> >>> used
> >>>>> to
> >>>>>>> create
> >>>>>>>> +decryption requests are placed in any of the data active queues and
> >>> are
> >>>>>>> ultimately handled by the
> >>>>>>> s/data active/active data/
> >>>>>>>> +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.
> >>>>>>>
> >>>>>>> [..]
> >>>>>>>
> >>>>>>>> ===============The below diff shows the changes of add
> >>> non-session
> >>>>> mode
> >>>>>>> support:
> >>>>>>>>
> >>>>>>>> diff --git a/virtio-crypto.tex b/virtio-crypto.tex
> >>>>>>>> index 884ee95..44819f9 100644
> >>>>>>>> --- a/virtio-crypto.tex
> >>>>>>>> +++ b/virtio-crypto.tex
> >>>>>>>> @@ -26,7 +26,10 @@ N is set by \field{max_dataqueues}.
> >>>>>>>>
> >>>>>>>> \subsection{Feature bits}\label{sec:Device Types / Crypto Device /
> >>>>> Feature
> >>>>>>> bits}
> >>>>>>>>
> >>>>>>>> -None currently defined.
> >>>>>>>> +VIRTIO_CRYPTO_F_CIPHER_SESSION_MODE (1) Session mode is
> >>>>> available
> >>>>>>> for CIPHER service.
> >>>>>>>> +VIRTIO_CRYPTO_F_HASH_SESSION_MODE (2) Session mode is
> >>> available
> >>>>> for
> >>>>>>> HASH service.
> >>>>>>>> +VIRTIO_CRYPTO_F_MAC_SESSION_MODE (3) Session mode is
> >>> available
> >>>>> for
> >>>>>>> MAC service.
> >>>>>>>> +VIRTIO_CRYPTO_F_AEAD_SESSION_MODE (4) Session mode is
> >>> available
> >>>>> for
> >>>>>>> AEAD service.
> >>>>>>>>
> >>>>>>>> \subsection{Device configuration layout}\label{sec:Device Types /
> >>>>> Crypto
> >>>>>>> Device / Device configuration layout}
> >>>>>>>>
> >>>>>>>> @@ -208,6 +211,9 @@ Operation parameters are
> >> algorithm-specific
> >>>>>>> parameters, output data is the
> >>>>>>>> data that should be utilized in operations, and input data is equal
> >> to
> >>>>>>>> "operation result + result data".
> >>>>>>>>
> >>>>>>>> +The device can support both session mode (See \ref{sec:Device
> >> Types
> >>> /
> >>>>>>> Crypto Device / Device Operation / Control Virtqueue / Session
> >>> operation})
> >>>>> and
> >>>>>>> non-session mode, for example,
> >>>>>>>> +As VIRTIO_CRYPTO_F_CIPHER_SESSION feature bit is negotiated,
> >>> the
> >>>>> driver
> >>>>>>> can use session mode for CIPHER service, otherwise it can only use
> >>>>> non-session
> >>>>>>> mode.
> >>>>>>>> +
> >>>>>>>
> >>>>>>> As far as I understand you are adding non-session mode to the mix but
> >>>>>>> providing feature bits for session mode. Would this render the the
> >>> current
> >>>>>>> implementation non-compliant?
> >>>>>>>
> >>>>>> You are right, shall we use feature bits for non-session mode for
> >>> compliancy?
> >>>>>> Or because the spec is on the fly, and some structures in the
> >>> virtio_crypto.h
> >>>>> need to
> >>>>>> be modified, can we keep the compliancy completely?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> -Gonglei
> >>>>>
> >>>>> Since there's a linux driver upstream you must at least
> >>>>> keep compatibility with that.
> >>>>>
> >>>> Sure. We use feature bits for non-session mode then.
> >>>> For structures modification, do we need to do some specific
> >>>> actions for compatibility? Take CIPHER service as an example:
> >>>>
> >>>> The present structure:
> >>>>
> >>>> struct virtio_crypto_cipher_para {
> >>>> /*
> >>>> * Byte Length of valid IV/Counter data pointed to by the below iv
> >> data.
> >>>> *
> >>>> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or
> >> for
> >>>> * SNOW3G in UEA2 mode, this is the length of the IV (which
> >>>> * must be the same as the block length of the cipher).
> >>>> * For block ciphers in CTR mode, this is the length of the counter
> >>>> * (which must be the same as the block length of the cipher).
> >>>> */
> >>>> le32 iv_len;
> >>>> /* length of source data */
> >>>> le32 src_data_len;
> >>>> /* length of destination data */
> >>>> le32 dst_data_len;
> >>>> };
> >>>>
> >>>> The future structure if supporting non-session based operations:
> >>>>
> >>>> struct virtio_crypto_cipher_para {
> >>>> struct {
> >>>> /* See VIRTIO_CRYPTO_CIPHER* above */
> >>>> le32 algo;
> >>>> /* length of key */
> >>>> le32 keylen;
> >>>>
> >>>> /* See VIRTIO_CRYPTO_OP_* above */
> >>>> le32 op;
> >>>> } sess_para;
> >>>>
> >>>> /*
> >>>> * Byte Length of valid IV/Counter data pointed to by the below iv
> >> data.
> >>>> *
> >>>> * For block ciphers in CBC or F8 mode, or for Kasumi in F8 mode, or
> >> for
> >>>> * SNOW3G in UEA2 mode, this is the length of the IV (which
> >>>> * must be the same as the block length of the cipher).
> >>>> * For block ciphers in CTR mode, this is the length of the counter
> >>>> * (which must be the same as the block length of the cipher).
> >>>> */
> >>>> le32 iv_len;
> >>>> /* length of source data */
> >>>> le32 src_data_len;
> >>>> /* length of destination data */
> >>>> le32 dst_data_len;
> >>>> };
> >>>>
> >>>> Thanks,
> >>>> -Gonglei
> >>>
> >>> So you will have to maintain both structures for when non-session based
> >>> feature is and aren't present. You will have to give them different
> >>> names, too.
> >>>
> >> OK, I get your point. :)
> >>
> >> Thanks,
> >> -Gonglei
> >
> >
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] RE: [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-17 2:49 ` Gonglei (Arei)
@ 2017-01-18 17:16 ` Halil Pasic
2017-01-19 1:43 ` Gonglei (Arei)
0 siblings, 1 reply; 18+ messages in thread
From: Halil Pasic @ 2017-01-18 17:16 UTC (permalink / raw)
To: Gonglei (Arei), Michael S. Tsirkin
Cc: Huangweidong (C), qemu-devel@nongnu.org, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, virtio-dev@lists.oasis-open.org,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
On 01/17/2017 03:49 AM, Gonglei (Arei) wrote:
> Hi Halil,
>
>>
>> On 01/16/2017 01:43 PM, Gonglei (Arei) wrote:
>>> Hi Michael and others,
>>>
>>> I'd like to redefine struct virtio_crypto_op_data_req is as below:
>>>
>>> struct virtio_crypto_op_data_req {
>>> 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;
>>> __u8 padding[72];
>>> } u;
>>> };
>>>
>>> The length of union in the structure will be changed, which from current 48
>> byte to 72 byte.
Quoting seems broken :(
>>>
>>> We couldn't redefine a structure named
>> virtio_crypto_op_data_req_non_sess,
>>> Because the feature bits are for crypto services, not for the wrapper packet
>> request.
>>>
>>
>> You mean virtio_crypto_op_data_req.virtio_crypto_op_header.flags
>> are conceptually meant for something else and using that field woulb
>> be misuse?
>>
> Nope...
>>
I'm having huge difficulties following you. Please tell me what was
the intended meaning of the sentence I commented! About which
flags are you talking?
>>> It's impossible to mixed use struct virtio_crypto_op_data_req and
>>> struct named virtio_crypto_op_data_req_non_sess for one data virtqueue.
>>>
>>
>> I do not understand what are you trying to say here. I think you
>> should tell us what is the new feature and how it is guarded.
>>
>> Would this mean that session or non-session mode will be tied
>> to the whole device, or to one data-queue. If it's data-queue
>> level how is it controlled (e.g. control queue)?
>>
> ... I'm so sorry for confusing explanation. Let me try to explain it more clear.
Which explanation? Now I see three ideas as a more clear explanation
where I figured we are discussing one idea.
>
> 1 ) The first idea: For support non-session mode crypto operations, I introduce 4 feature bits
> for different crypto services, they are:
>
> VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is available for CIPHER service.
> VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is available for HASH service.
> VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is available for MAC service.
> VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is available for AEAD service.
>
> but not only one feature bit, something like:
>
> VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
>
> Meanwhile, I define 4 new non-session mode structures for different crypto
> services in order to keep compatibility to pre-existing driver.
>
> -*Advantages*:
>
> a) We can support different modes for different crypto services
> according to which features are negotiated.
>
> b) The driver can still use the session mode when VIRTIO_CRYPTO_F_*_NON_SESSION_MODE are negotiated,
> which is under control by virtio_crypto_op_data_req.virtio_crypto_op_header.flags.
>
> - *Disadvantages*:
>
> The current crypto packets of all
> crypto services (CIPHER, HASH, MAC and AEAD) are wrapped in structure
> virtio_crypto_op_data_req by an union in the data plane.
>
> It will change the length of the union and break the pre-existing code
> if still lay all non-session mode structures in strut virtio_crypto_op_data_req
> like this:
>
> struct virtio_crypto_op_data_req {
> 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;
> __u8 padding[72];
> } u;
> };
Yeah if you say a request has to look like this regardless
of negotiated features, then you render the currently upstream
code non-conform. That's pretty much a decisive disadvantage!
>
> So I should submit patches to fix them.
And IMHO you can not fix that with patches because it's already
released -- and you would have to travel back in time to fix
it in time.
>
> 2) Another idea is define a non-session mode structure for strut virtio_crypto_op_data_req.
>
> struct virtio_crypto_op_data_req_non_sess {
> struct virtio_crypto_op_header header;
>
> union {
> 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;
> __u8 padding[72];
> } u;
> };
>
> And keep the pre-existing strut virtio_crypto_op_data_req:
>
> struct virtio_crypto_op_data_req {
> 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;
> __u8 padding[48];
> } u;
> };
>
> - *Advantages*:
>
> Don't break the pre-existing code.
>
> - *Disadvantages*:
>
> Can't support feature bits for different crypto services,
> only the whole device. That means we should only use the below feature
I do not see why, and I do not see why should we want to have
separate feature bits for each service.
> bit:
>
> VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
>
>
> 3) The last idea is define a mixed structure for strut virtio_crypto_op_data_req.
>
> 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;
> __u8 padding[72];
> } u;
> };
>
> And keep the pre-existing strut virtio_crypto_op_data_req:
>
> struct virtio_crypto_op_data_req {
> 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;
> __u8 padding[48];
> } u;
> };
>
> That means we should use below five feature bits:
>
> VIRTIO_CRYPTO_F_ NON_SESSION_MODE (0) non-session mode is available.
> VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is available for CIPHER service.
> VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is available for HASH service.
> VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is available for MAC service.
> VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is available for AEAD service.
>
> -*Advantages*:
>
> Both idea 1) and 2).
>
> -*Disadvantages*:
>
> None.
>
> What's your opinion? Thanks a lot!
>
>
You kindly forget to tell us how it is to be decided which of the unioned
types is actually relevant for an instance. And also forget to tell
us which struct is used under which circumstances (that is feature
bits).
Well it does not matter. Have seen v16 and there you went for idea 3,
and decided to use virtio_crypto_op_header.flags to decide if we
have a session based or a stateless request at hand if feature bits
allow both. I will try to do a proper review there.
My opinion is that you should be more precise when describing
your ideas if you want to hear a more constrictive opinion than
this one.
Cheers,
Halil
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Qemu-devel] [virtio-dev] RE: [virtio-dev] Re: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-18 17:16 ` [Qemu-devel] [virtio-dev] " Halil Pasic
@ 2017-01-19 1:43 ` Gonglei (Arei)
0 siblings, 0 replies; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-19 1:43 UTC (permalink / raw)
To: Halil Pasic, Michael S. Tsirkin
Cc: Huangweidong (C), qemu-devel@nongnu.org, john.griffin@intel.com,
cornelia.huck@de.ibm.com, Zhoujian (jay, Euler),
Varun.Sethi@freescale.com, denglingli@chinamobile.com,
arei.gonglei@hotmail.com, virtio-dev@lists.oasis-open.org,
agraf@suse.de, nmorey@kalray.eu, vincent.jardin@6wind.com,
Ola.Liljedahl@arm.com, Luonengjun, xin.zeng@intel.com,
liang.j.ma@intel.com, stefanha@redhat.com, Shiqing Fan,
Jani Kokkonen, brian.a.keating@intel.com, Claudio Fontana,
mike.caraman@nxp.com, Wubin (H)
>
> On 01/17/2017 03:49 AM, Gonglei (Arei) wrote:
> > Hi Halil,
> >
> >>
> >> On 01/16/2017 01:43 PM, Gonglei (Arei) wrote:
> >>> Hi Michael and others,
> >>>
> >>> I'd like to redefine struct virtio_crypto_op_data_req is as below:
> >>>
> >>> struct virtio_crypto_op_data_req {
> >>> 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;
> >>> __u8 padding[72];
> >>> } u;
> >>> };
> >>>
> >>> The length of union in the structure will be changed, which from current 48
> >> byte to 72 byte.
>
> Quoting seems broken :(
>
> >>>
> >>> We couldn't redefine a structure named
> >> virtio_crypto_op_data_req_non_sess,
> >>> Because the feature bits are for crypto services, not for the wrapper
> packet
> >> request.
> >>>
> >>
> >> You mean virtio_crypto_op_data_req.virtio_crypto_op_header.flags
> >> are conceptually meant for something else and using that field woulb
> >> be misuse?
> >>
> > Nope...
> >>
>
> I'm having huge difficulties following you. Please tell me what was
> the intended meaning of the sentence I commented! About which
> flags are you talking?
>
> >>> It's impossible to mixed use struct virtio_crypto_op_data_req and
> >>> struct named virtio_crypto_op_data_req_non_sess for one data virtqueue.
> >>>
> >>
> >> I do not understand what are you trying to say here. I think you
> >> should tell us what is the new feature and how it is guarded.
> >>
> >> Would this mean that session or non-session mode will be tied
> >> to the whole device, or to one data-queue. If it's data-queue
> >> level how is it controlled (e.g. control queue)?
> >>
> > ... I'm so sorry for confusing explanation. Let me try to explain it more clear.
>
> Which explanation? Now I see three ideas as a more clear explanation
> where I figured we are discussing one idea.
>
> >
> > 1 ) The first idea: For support non-session mode crypto operations, I introduce
> 4 feature bits
> > for different crypto services, they are:
> >
> > VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is
> available for CIPHER service.
> > VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is
> available for HASH service.
> > VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is
> available for MAC service.
> > VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is
> available for AEAD service.
> >
> > but not only one feature bit, something like:
> >
> > VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
> >
> > Meanwhile, I define 4 new non-session mode structures for different crypto
> > services in order to keep compatibility to pre-existing driver.
> >
> > -*Advantages*:
> >
> > a) We can support different modes for different crypto services
> > according to which features are negotiated.
> >
> > b) The driver can still use the session mode when
> VIRTIO_CRYPTO_F_*_NON_SESSION_MODE are negotiated,
> > which is under control by
> virtio_crypto_op_data_req.virtio_crypto_op_header.flags.
> >
> > - *Disadvantages*:
> >
> > The current crypto packets of all
> > crypto services (CIPHER, HASH, MAC and AEAD) are wrapped in structure
> > virtio_crypto_op_data_req by an union in the data plane.
> >
> > It will change the length of the union and break the pre-existing code
> > if still lay all non-session mode structures in strut virtio_crypto_op_data_req
> > like this:
> >
> > struct virtio_crypto_op_data_req {
> > 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;
> > __u8 padding[72];
> > } u;
> > };
>
> Yeah if you say a request has to look like this regardless
> of negotiated features, then you render the currently upstream
> code non-conform. That's pretty much a decisive disadvantage!
>
> >
> > So I should submit patches to fix them.
>
> And IMHO you can not fix that with patches because it's already
> released -- and you would have to travel back in time to fix
> it in time.
>
> >
> > 2) Another idea is define a non-session mode structure for strut
> virtio_crypto_op_data_req.
> >
> > struct virtio_crypto_op_data_req_non_sess {
> > struct virtio_crypto_op_header header;
> >
> > union {
> > 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;
> > __u8 padding[72];
> > } u;
> > };
> >
> > And keep the pre-existing strut virtio_crypto_op_data_req:
> >
> > struct virtio_crypto_op_data_req {
> > 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;
> > __u8 padding[48];
> > } u;
> > };
> >
> > - *Advantages*:
> >
> > Don't break the pre-existing code.
> >
> > - *Disadvantages*:
> >
> > Can't support feature bits for different crypto services,
> > only the whole device. That means we should only use the below feature
>
> I do not see why, and I do not see why should we want to have
> separate feature bits for each service.
>
That's because we need fine control so that we can know use session or
non-session based packet structure for each crypto services.
> > bit:
> >
> > VIRTIO_CRYPTO_F_ NON_SESSION_MODE (1) non-session mode is available.
> >
> >
> > 3) The last idea is define a mixed structure for strut
> virtio_crypto_op_data_req.
> >
> > 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;
> > __u8 padding[72];
> > } u;
> > };
> >
> > And keep the pre-existing strut virtio_crypto_op_data_req:
> >
> > struct virtio_crypto_op_data_req {
> > 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;
> > __u8 padding[48];
> > } u;
> > };
> >
> > That means we should use below five feature bits:
> >
> > VIRTIO_CRYPTO_F_ NON_SESSION_MODE (0) non-session mode is available.
> > VIRTIO_CRYPTO_F_CIPHER_NON_SESSION_MODE (1) non-session mode is
> available for CIPHER service.
> > VIRTIO_CRYPTO_F_HASH_NON_SESSION_MODE (2) non-session mode is
> available for HASH service.
> > VIRTIO_CRYPTO_F_MAC_NON_SESSION_MODE (3) non-session mode is
> available for MAC service.
> > VIRTIO_CRYPTO_F_AEAD_NON_SESSION_MODE (4) non-session mode is
> available for AEAD service.
> >
> > -*Advantages*:
> >
> > Both idea 1) and 2).
> >
> > -*Disadvantages*:
> >
> > None.
> >
> > What's your opinion? Thanks a lot!
> >
> >
>
> You kindly forget to tell us how it is to be decided which of the unioned
> types is actually relevant for an instance. And also forget to tell
> us which struct is used under which circumstances (that is feature
> bits).
>
Exactly, there're some descriptions in v16.
> Well it does not matter. Have seen v16 and there you went for idea 3,
> and decided to use virtio_crypto_op_header.flags to decide if we
> have a session based or a stateless request at hand if feature bits
> allow both. I will try to do a proper review there.
>
Yes. Looking forward to your feedback, thanks!
> My opinion is that you should be more precise when describing
> your ideas if you want to hear a more constrictive opinion than
> this one.
>
Sure, sorry about that.
Thanks,
-Gonglei
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
2017-01-04 10:03 [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei
` (2 preceding siblings ...)
2017-01-04 10:10 ` [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Gonglei (Arei)
@ 2017-01-12 11:27 ` Gonglei (Arei)
3 siblings, 0 replies; 18+ messages in thread
From: Gonglei (Arei) @ 2017-01-12 11:27 UTC (permalink / raw)
To: Gonglei (Arei), qemu-devel@nongnu.org,
virtio-dev@lists.oasis-open.org
Cc: Luonengjun, mst@redhat.com, cornelia.huck@de.ibm.com,
stefanha@redhat.com, denglingli@chinamobile.com, Jani Kokkonen,
Ola.Liljedahl@arm.com, Varun.Sethi@freescale.com,
xin.zeng@intel.com, brian.a.keating@intel.com,
liang.j.ma@intel.com, john.griffin@intel.com, Huangweidong (C),
mike.caraman@nxp.com, agraf@suse.de, Claudio Fontana,
Zhoujian (jay, Euler), nmorey@kalray.eu, vincent.jardin@6wind.com,
Wubin (H), Shiqing Fan, arei.gonglei@hotmail.com,
pasic@linux.vnet.ibm.com
Ping...
Any Comments?
Thanks,
-Gonglei
> -----Original Message-----
> From: Gonglei (Arei)
> Sent: Wednesday, January 04, 2017 6:03 PM
> To: qemu-devel@nongnu.org; virtio-dev@lists.oasis-open.org
> Cc: Luonengjun; mst@redhat.com; cornelia.huck@de.ibm.com;
> stefanha@redhat.com; denglingli@chinamobile.com; Jani Kokkonen;
> Ola.Liljedahl@arm.com; Varun.Sethi@freescale.com; xin.zeng@intel.com;
> brian.a.keating@intel.com; liang.j.ma@intel.com; john.griffin@intel.com;
> Huangweidong (C); mike.caraman@nxp.com; agraf@suse.de; Claudio Fontana;
> Zhoujian (jay, Euler); nmorey@kalray.eu; vincent.jardin@6wind.com; Wubin (H);
> Shiqing Fan; arei.gonglei@hotmail.com; pasic@linux.vnet.ibm.com; Gonglei
> (Arei)
> Subject: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification
>
> Changes since v14:
> - drop VIRTIO_CRYPTO_S_STARTED status [Halil & Cornelia]
> - correct a sentence about dataqueue and controlq in the first paragraph.
> [Halil]
> - change a MAY to MUST about max_dataqueues. [Halil]
> - add non-session mode support
> 1) add four features for different crypto services to identify wheather
> support session mode.
> 2) extend virtio_crypto_*_para structures, for example, add the content of
> struct virtio_crypto_cipher_session_para into struct
> virtio_crypto_cipher_para.
> 3) use the flag property of struct virtio_crypto_op_header to identify the
> type of crypto request. Aka Is it a session-based or non-session request
>
> For pervious versions of virtio crypto spec, Pls see:
>
> [v14]:
> https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg02212.html
>
> [v13]:
> https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg07348.html
>
> For more information, please see:
> http://qemu-project.org/Features/VirtioCrypto
>
> Please help to review, thanks.
>
> Gonglei (2):
> virtio-crypto: Add virtio crypto device specification
> virtio-crypto: Add conformance clauses
>
> conformance.tex | 30 ++
> content.tex | 2 +
> virtio-crypto.tex | 1029
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1061 insertions(+)
> create mode 100644 virtio-crypto.tex
>
> --
> 1.7.12.4
>
^ permalink raw reply [flat|nested] 18+ messages in thread