From patchwork Wed Jan 4 10:10:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Gonglei (Arei)" X-Patchwork-Id: 9496389 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 8310F60413 for ; Wed, 4 Jan 2017 10:11:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 64A4127B13 for ; Wed, 4 Jan 2017 10:11:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5509827D8D; Wed, 4 Jan 2017 10:11:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 595FB27B13 for ; Wed, 4 Jan 2017 10:11:13 +0000 (UTC) Received: from localhost ([::1]:38265 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOiXI-0003N1-7Z for patchwork-qemu-devel@patchwork.kernel.org; Wed, 04 Jan 2017 05:11:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOiWy-0003Mu-V7 for qemu-devel@nongnu.org; Wed, 04 Jan 2017 05:10:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOiWs-00025E-LA for qemu-devel@nongnu.org; Wed, 04 Jan 2017 05:10:52 -0500 Received: from [45.249.212.188] (port=2434 helo=dggrg02-dlp.huawei.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1cOiWq-0001xg-51 for qemu-devel@nongnu.org; Wed, 04 Jan 2017 05:10:46 -0500 Received: from 172.30.72.54 (EHLO DGGEMA404-HUB.china.huawei.com) ([172.30.72.54]) by dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AGL37037; Wed, 04 Jan 2017 18:10:26 +0800 (CST) Received: from DGGEMA505-MBX.china.huawei.com ([169.254.1.226]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0301.000; Wed, 4 Jan 2017 18:10:06 +0800 From: "Gonglei (Arei)" To: "Gonglei (Arei)" , "qemu-devel@nongnu.org" , "virtio-dev@lists.oasis-open.org" Thread-Topic: [PATCH v15 0/2] virtio-crypto: virtio crypto device specification Thread-Index: AQHSZnHL3M8H/oKxfUaUJyOUF98EUaEoFvbg Date: Wed, 4 Jan 2017 10:10:05 +0000 Message-ID: <33183CC9F5247A488A2544077AF19020DA174989@DGGEMA505-MBX.china.huawei.com> References: <1483524185-9036-1-git-send-email-arei.gonglei@huawei.com> In-Reply-To: <1483524185-9036-1-git-send-email-arei.gonglei@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.18.62] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.586CCA16.01EC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.226, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1043fcd8dc3bf7b6b8e55aec8c00af4b X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 45.249.212.188 Subject: Re: [Qemu-devel] [PATCH v15 0/2] virtio-crypto: virtio crypto device specification X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 , "pasic@linux.vnet.ibm.com" , "brian.a.keating@intel.com" , Claudio Fontana , "mike.caraman@nxp.com" , "Wubin \(H\)" Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hi all, I attach the diff files between v14 and v15 for better review. 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 > 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