All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>
To: Srujana Challa <schalla@marvell.com>
Cc: virtio-comment@lists.linux.dev, mst@redhat.com,
	cohuck@redhat.com, parav@nvidia.com, sburla@marvell.com,
	ndabilpuram@marvell.com, jerinj@marvell.com, anoobj@marvell.com
Subject: Re: [PATCH RFC 3/4] virtio-crypto: Add new IPsec opcodes to data request
Date: Thu, 12 Dec 2024 10:46:16 +0100	[thread overview]
Message-ID: <Z1qw6EwP8de2PgqP@fedora> (raw)
In-Reply-To: <20241115114523.1787840-4-schalla@marvell.com>

On Fri, Nov 15, 2024 at 05:15:22PM +0530, Srujana Challa wrote:
> Adds new IPsec opcodes, VIRTIO_CRYPTO_IPSEC_OUTBOUND and
> VIRTIO_CRYPTO_IPSEC_INBOUND and defines opcode specific
> data structures for IPsec data processing.
> 
> Signed-off-by: Srujana Challa <schalla@marvell.com>
> ---

Reviewed-by: Matias Ezequiel Vara Larsen <mvaralar@redhat.com>


>  device-types/crypto/description.tex | 81 ++++++++++++++++++++++++++++-
>  1 file changed, 80 insertions(+), 1 deletion(-)
> 
> diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
> index 7ac6f5b..9c878f7 100644
> --- a/device-types/crypto/description.tex
> +++ b/device-types/crypto/description.tex
> @@ -990,6 +990,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;
> @@ -1007,6 +1011,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:
> @@ -1094,6 +1109,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
> @@ -1914,8 +1936,23 @@ \subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device /
>  in tunnel mode, as well as the ESP/AH header from the packet. The resulting
>  packet contains only the plain data.
>  
> +The driver can offload 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 will perform encryption, attach ICV,
> -update/add IP headers, add ESP/AH headers/trailers.
> +update/add IP headers, add ESP/AH headers/trailers during data processing.
> +
> +The driver can offload IPsec outbound processing by creating outbound SAs
> +\begin{itemize*}
> +\item Creating inbound 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*}
> +See \ref{sec:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Data processing}
>  
>  A crypto device can support number of IPsec SAs, allowing it to manage multiple secure
>  connections simultaneously.
> @@ -2159,3 +2196,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 SHOULD 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
> 
> 


  reply	other threads:[~2024-12-12  9:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-15 11:45 [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto Srujana Challa
2024-11-15 11:45 ` [PATCH RFC 1/4] virtio-crypto: Add IPsec service operation and Capabilities Srujana Challa
2024-12-05 12:04   ` Matias Ezequiel Vara Larsen
2024-12-06  7:05     ` [EXTERNAL] " Srujana Challa
2024-11-15 11:45 ` [PATCH RFC 2/4] virtio-crypto: Add resource objects for IPsec outbound and inbound SAs Srujana Challa
2024-12-07 12:24   ` Matias Ezequiel Vara Larsen
2024-11-15 11:45 ` [PATCH RFC 3/4] virtio-crypto: Add new IPsec opcodes to data request Srujana Challa
2024-12-12  9:46   ` Matias Ezequiel Vara Larsen [this message]
2024-11-15 11:45 ` [PATCH RFC 4/4] virtio-crypto: Add device and driver requirements for IPsec operation Srujana Challa
2024-12-12 10:15   ` Matias Ezequiel Vara Larsen
2024-12-12 10:19 ` [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto Matias Ezequiel Vara Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z1qw6EwP8de2PgqP@fedora \
    --to=mvaralar@redhat.com \
    --cc=anoobj@marvell.com \
    --cc=cohuck@redhat.com \
    --cc=jerinj@marvell.com \
    --cc=mst@redhat.com \
    --cc=ndabilpuram@marvell.com \
    --cc=parav@nvidia.com \
    --cc=sburla@marvell.com \
    --cc=schalla@marvell.com \
    --cc=virtio-comment@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.