RE: [PATCH RFC v6 3/4] virtio-crypto: Add new IPsec opcodes to data request

> From: Srujana Challa <[email protected]>
> Sent: Thursday, April 24, 2025 3:01 PM
> 
> Adds new IPsec opcodes, VIRTIO_CRYPTO_IPSEC_OUTBOUND and
> VIRTIO_CRYPTO_IPSEC_INBOUND and defines opcode specific data structures
> for IPsec data processing.
> 
> Reviewed-by: Matias Ezequiel Vara Larsen <[email protected]>
> Reviewed-by: Parav Pandit <[email protected]>
> Signed-off-by: Srujana Challa <[email protected]>
> ---
>  device-types/crypto/description.tex | 84 +++++++++++++++++++++++++++++
>  1 file changed, 84 insertions(+)
> 
> diff --git a/device-types/crypto/description.tex b/device-
> types/crypto/description.tex
> index 544ac18..794b9b4 100644
> --- a/device-types/crypto/description.tex
> +++ b/device-types/crypto/description.tex
> @@ -379,6 +379,7 @@ \subsubsection{Operation Status}\label{sec:Device
> Types / Crypto Device / Device
>      VIRTIO_CRYPTO_INVSESS = 4,
>      VIRTIO_CRYPTO_NOSPC = 5,
>      VIRTIO_CRYPTO_KEY_REJECTED = 6,
> +    VIRTIO_CRYPTO_IPSEC_SA_SOFT_EXPIRY = 7,
>      VIRTIO_CRYPTO_MAX
>  };
>  \end{lstlisting}
> @@ -391,6 +392,9 @@ \subsubsection{Operation Status}\label{sec:Device
> Types / Crypto Device / Device  \item VIRTIO_CRYPTO_NOSPC: no free session
> ID (only when the VIRTIO_CRYPTO_F_REVISION_1
>      feature bit is negotiated).
>  \item VIRTIO_CRYPTO_KEY_REJECTED: signature verification failed (only
> when AKCIPHER verification).
> +\item VIRTIO_CRYPTO_IPSEC_SA_SOFT_EXPIRY: IPsec SA lifetime soft limits
> are reached.
> +    When VIRTIO_CRYPTO_IPSEC_SA_SOFT_EXPIRY occurs, the request is
> completed successfully,
> +    but one or all of the soft limits are reached. This is applicable only for
> IPsec service operations.
>  \item VIRTIO_CRYPTO_ERR: any failure not mentioned above occurs.
>  \end{itemize*}
> 
It would be good to have the error code for SA_HARD_EXPIRY case.
VIRTIO_CRYPTO_ERR can be used , however since there is concept if SOFT_EXPIRY status code, for completeness we should have HARD_EXPIRY code.

This will be hard to do in vnet case. Yet to check.

> @@ -992,6 +996,10 @@ \subsubsection{Data Virtqueue}\label{sec:Device
> Types / Crypto Device / Device O
>      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x02)
> #define VIRTIO_CRYPTO_AKCIPHER_VERIFY \
>      VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_AKCIPHER, 0x03)
> +#define VIRTIO_CRYPTO_IPSEC_OUTBOUND \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_IPSEC, 0x00) #define
> +VIRTIO_CRYPTO_IPSEC_INBOUND \
> +    VIRTIO_CRYPTO_OPCODE(VIRTIO_CRYPTO_SERVICE_IPSEC, 0x01)
>      le32 opcode;
>      /* algo should be service-specific algorithms */
>      le32 algo;
> @@ -1009,6 +1017,17 @@ \subsubsection{Data Virtqueue}\label{sec:Device
> Types / Crypto Device / Device O  If VIRTIO_CRYPTO_F_REVISION_1 is
> negotiated but VIRTIO_CRYPTO_F_<SERVICE>_STATELESS_MODE
>  is not negotiated, then the device SHOULD reject <SERVICE> requests if
> VIRTIO_CRYPTO_FLAG_SESSION_MODE is not set (in \field{flag}).
> +
> +For VIRTIO_CRYPTO_IPSEC_OUTBOUND and
> VIRTIO_CRYPTO_IPSEC_INBOUND
> +opcodes, \field{algo} is ignored.
> +
> +For VIRTIO_CRYPTO_IPSEC_OUTBOUND opcode, \field{session_id} MUST be
> set
> +to one of the resource objects \field{id} created using
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA resource type.
> +
> +For VIRTIO_CRYPTO_IPSEC_INBOUND opcode, \field{session_id} MUST be
> set
> +to one of the resource objects \field{id} created using
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA resource type.
>  \end{note}
> 
>  The dataq request is composed of four parts:
> @@ -1096,6 +1115,13 @@ \subsubsection{Data Virtqueue}\label{sec:Device
> Types / Crypto Device / Device O
>          and struct virtio_crypto_akcipher_data_flf is padded to 48 bytes if NOT
> negotiated,
>          and \field{op_vlf} is struct virtio_crypto_akcipher_data_vlf.
>      \end{itemize*}
> +\item If the the opcode (in \field{header}) is
> VIRTIO_CRYPTO_IPSEC_OUTBOUND
> +    or VIRTIO_CRYPTO_IPSEC_INBOUND then:
> +    \begin{itemize*}
> +    \item \field{op_flf} is struct virtio_crypto_ipsec_data_flf and
> +        \field{op_vlf} is struct virtio_crypto_ipsec_data_vlf.
> +	Works only for session mode.
> +    \end{itemize*}
>  \end{itemize*}
> 
>  \field{inhdr} is a unified input header that used to return the status of @@ -
> 1916,12 +1942,28 @@ \subsubsection{IPSEC Service
> Operation}\label{sec:Device Types / Crypto Device /  in tunnel mode, as well
> as the ESP/AH header on the given packet(See \hyperref[intro:IPSEC]{IPSEC}
> RFC).
>  The resulting packet contains only the plain data.
> 
> +The driver can request IPsec Inbound processing by \begin{itemize*}
> +\item Creating inbound SAs using the
> VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA command.
> +\item Setting the \field{opcode} in struct virtio_crypto_op_data_req to
> +VIRTIO_CRYPTO_IPSEC_INBOUND.
> +\end{itemize*}
> +
>  IPsec Outbound processing: The device performs encryption, attach ICV,
> update/add IP header and add ESP/AH header/trailer. The resulting packet
> contains encrypted data along with the IPsec header and trailer.
> 
> +The driver can request IPsec outbound processing by \begin{itemize*}
> +\item Creating outbound SAs using the
> VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA command.
> +\item Setting the \field{opcode} in struct virtio_crypto_op_data_req to
> +VIRTIO_CRYPTO_IPSEC_OUTBOUND.
> +\end{itemize*}
> +
>  A crypto device can support number of IPsec SAs, allowing it to manage
> multiple secure  connections simultaneously.
> +See \ref{sec:Device Types / Crypto Device / Device Operation / IPsec
> +Service Operation / Resource objects} for IPsec SA information.
> 
>  The device and the driver indicate IPsec SA resource limits using the
> VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP capability specifying the limits on the
> number of @@ -2191,3 +2233,45 @@ \subsubsection{IPSEC Service
> Operation}\label{sec:Device Types / Crypto Device /  capability
> VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP. For the IPsec inbound SA resource
> object  \field{resource_obj_specific_data} is in the format  \field{struct
> virtio_crypto_resource_obj_ipsec_sa}.
> +
> +\paragraph{Data processing}
> +\label{par:Device Types / Crypto Device / Device Operation / IPsec
> +Service Operation / Data processing}
> +
> +Data requests for IPsec processing are as follows:
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ipsec_data_flf {
> +        /* length of source data, full IP/IPsec packet */
> +        le32 src_data_len;
> +        /* length of dst data */
> +        le32 dst_data_len;
> +};
> +
> +struct virtio_crypto_ipsec_data_vlf {
> +        /* Device read only portion */
> +        /* Source data */
> +        u8 src_data[src_data_len];
> +
> +        /* Device write only portion */
> +        /* Pointer to output data */
> +        u8 dst_data[dst_data_len];
> +};
> +\end{lstlisting}
> +
> +Each data request uses the virtio_crypto_ipsec_data_flf structure and
> +the virtio_crypto_ipsec_data_vlf structure to store information used to
> +run the IPSEC operations.
> +
> +For IPsec encryption:
> +\field{src_data} is the full IP packet that will be processed.
> +\field{src_data_len} is the length of source data.
> +\field{dst_result} is the result ESP encrypted packet and
> +\field{dst_data_len} is the length of it. Please note, dst_data_len
> +MUST include additional header and trailer lengths.
> +
> +For IPsec decryption:
> +\field{src_data} is the IPsec packet that will be processed.
> +\field{src_data_len} is the length of source data.
> +\field{dst_result} is the result plain IP packet and
> +\field{dst_data_len} is the length of it.
> --
> 2.25.1

Apart from above comment,
Reviewed-by: Parav Pandit <[email protected]>