* [PATCH RFC 1/4] virtio-crypto: Add IPsec service operation and Capabilities
2024-11-15 11:45 [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto Srujana Challa
@ 2024-11-15 11:45 ` Srujana Challa
2024-12-05 12:04 ` Matias Ezequiel Vara Larsen
2024-11-15 11:45 ` [PATCH RFC 2/4] virtio-crypto: Add resource objects for IPsec outbound and inbound SAs Srujana Challa
` (3 subsequent siblings)
4 siblings, 1 reply; 11+ messages in thread
From: Srujana Challa @ 2024-11-15 11:45 UTC (permalink / raw)
To: virtio-comment
Cc: mst, cohuck, parav, sburla, ndabilpuram, jerinj, anoobj, schalla
This commit introduces the IPsec service operation to the Crypto
device, enabling offloading of IPsec processing.
Capabilities:
1. IPsec Resource Capability (VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP):
Indicates the device's IPsec resource limits, such as the number of
outbound and inbound Security Associations (SAs).
2. IPsec SA Capability (VIRTIO_CRYPTO_IPSEC_SA_CAP): Specifies the
supported IPsec modes, along with the supported cryptographic
algorithms, authentication algorithms, IPsec options and
anti-replay window size.
Signed-off-by: Srujana Challa <schalla@marvell.com>
---
device-types/crypto/description.tex | 164 +++++++++++++++++++++++++++-
1 file changed, 159 insertions(+), 5 deletions(-)
diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
index 5705e26..ce4b1fb 100644
--- a/device-types/crypto/description.tex
+++ b/device-types/crypto/description.tex
@@ -2,11 +2,11 @@ \section{Crypto Device}\label{sec:Device Types / Crypto Device}
The virtio crypto device is a virtual cryptography device as well as a
virtual cryptographic accelerator. The virtio crypto device provides the
-following crypto services: CIPHER, MAC, HASH, AEAD and AKCIPHER. Virtio crypto
-devices have a single control queue and at least one data queue. Crypto
-operation requests are placed into a data queue, and serviced by the
-device. Some crypto operation requests are only valid in the context of a
-session. The role of the control queue is facilitating control operation
+following crypto services: CIPHER, MAC, HASH, AEAD, AKCIPHER and IPSEC.
+Virtio crypto devices have a single control queue and at least one data
+queue. Crypto operation requests are placed into a data queue, and serviced
+by the device. Some crypto operation requests are only valid in the context
+of a session. The role of the control queue is facilitating control operation
requests. Sessions management is realized with control operation
requests.
@@ -72,6 +72,8 @@ \subsection{Supported crypto services}\label{sec:Device Types / Crypto Device /
#define VIRTIO_CRYPTO_SERVICE_AEAD 3
/* AKCIPHER (Asymmetric Key Cipher) service */
#define VIRTIO_CRYPTO_SERVICE_AKCIPHER 4
+/* IPSEC service */
+#define VIRTIO_CRYPTO_SERVICE_IPSEC 5
\end{lstlisting}
The above constants designate bits used to indicate the which of crypto services are
@@ -318,6 +320,20 @@ \subsection{Device Initialization}\label{sec:Device Types / Crypto Device / Devi
\item The driver MUST read the supported algorithms based on \field{crypto_services} field.
\end{itemize*}
+\subsection{Device and driver capabilities}\label{sec:Device Types / Crypto Device / Device and driver capabilities}
+
+The crypto device has the following capabilities.
+
+\begin{tabularx}{\textwidth}{ |l||l|X| }
+\hline
+Identifier & Name & Description \\
+\hline \hline
+0x0800 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-RESOURCE-CAP]{VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP} & IPsec resource capability \\
+\hline
+0x0801 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP]{VIRTIO_CRYPTO_IPSEC_SA_CAP} & IPsec Security Association(SA) capability \\
+\hline
+\end{tabularx}
+
\subsection{Device Operation}\label{sec:Device Types / Crypto Device / Device Operation}
The operation of a virtio crypto device is driven by requests placed on the virtqueues.
@@ -1872,3 +1888,141 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
\item VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
\end{itemize*}
\end{itemize*}
+
+\subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device / Device Operation / IPSEC Service Operation}
+
+A crypto device can support the programming of IPsec Security Associations(SAs).
+In addition to standard crypto processing, the IPsec protocol processing is
+also offloaded to the Crypto Device as lookaside operation.
+
+IPsec Inbound processing: The device will perform decryption, authentication,
+integrity checking and remove additional headers, including tunnel headers if
+in tunnel mode, as well as the ESP/AH header from the packet. The resulting
+packet contains only the plain data.
+
+IPsec Outbound processing: The device will perform encryption, attach ICV,
+update/add IP headers, add ESP/AH headers/trailers.
+
+A crypto device can support number of IPsec SAs, allowing it to manage multiple secure
+connections simultaneously.
+
+The device and the driver indicates IPsec SA resource limits using the capability
+VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP specifying the limits on the number of IPsec outbound and
+inbound SA resource objects.
+The capability VIRTIO_CRYPTO_IPSEC_SA_CAP specifies which IPsec protocol capabilities
+the device supports. The driver indicates the IPsec parameters(Crypto algorithm,
+IPsec mode, anti-replay window size, etc.) it is using by setting the IPsec SA capability,
+prior to adding any resource objects.
+
+The driver controls the IPsec SA resource objects using administration commands described in
+\ref{sec:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Device resource objects}.
+
+\paragraph{Device and driver capabilities}
+\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities}
+
+\subparagraph{VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP}
+\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-RESOURCE-CAP}
+
+The capability VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP indicates the IPsec SA resource limits.
+\field{cap_specific_data} is in the format
+\field{struct virtio_crypto_ipsec_resource_cap}.
+
+\begin{lstlisting}
+struct virtio_crypto_ipsec_resource_cap {
+ le32 inb_sa_limit;
+ le32 outb_sa_limit;
+};
+\end{lstlisting}
+
+\field{inb_sa_limit}, and \field{outb_sa_limit} denote the maximum number of IPsec
+security Associations (SAs) that can be utilized for IPsec inbound and outbound processing,
+respectively, which the device is capable of creating.
+
+\subparagraph{VIRTIO_CRYPTO_IPSEC_SA_CAP}
+\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP}
+
+The capability VIRTIO_CRYPTO_IPSEC_SA_CAP lists the supported IPsec modes along with
+the supported cryptographic, authentication algorithms and anti-replay window size for
+each IPsec mode.
+\field{cap_specific_data} is in the format \field{struct virtio_crypto_ipsec_sa_cap_data}.
+
+\begin{lstlisting}[label={lst:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / virtio-crypto-ipsec-mode-cap}]
+struct virtio_crypto_ipsec_mode_cap {
+ le32 replay_win_sz_max;
+ le32 options;
+ le64 cipher_algo;
+ le64 hmac_algo;
+ le32 aead_algo;
+ le32 max_cipher_key_len;
+ le32 max_auth_key_len;
+ u8 mode;
+ u8 padding[3];
+};
+
+struct virtio_crypto_ipsec_sa_cap_data {
+ u8 count;
+ u8 reserved[7];
+ struct virtio_crypto_ipsec_mode_cap mode[];
+};
+\end{lstlisting}
+
+\field{count} indicates number of valid entries in the \field{mode} array.
+\field{mode[]} is an array of supported IPsec modes. Within each array entry:
+
+\field{mode} specifies the IPsec mode, as defined in table
+\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}.
+\field{replay_win_sz_max} specifies the maximum anti-replay window size the device supports.
+
+\field{options} represents the IPsec protocol options the device supports, as defined in table
+\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}.
+
+\field{cipher_algo} CIPHER algorithms mask, see \ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}.
+
+\field{hmac_algo} HMAC algorithms mask, see \ref{sec:Device Types / Crypto Device / Supported crypto services / MAC services}.
+
+\field{aead_algo} AEAD algorithms mask, see \ref{sec:Device Types / Crypto Device / Supported crypto services / AEAD services}.
+
+\field{max_cipher_key_len} is the maximum length of cipher key supported by the device.
+
+\field{max_auth_key_len} is the maximum length of authenticated key supported by the device.
+
+\begin{table}[H]
+\caption{IPsec Modes}
+\label{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}
+\begin{tabularx}{\textwidth}{ |l|X|X| }
+\hline
+Type & Name & Description \\
+\hline \hline
+0x0 & - & Reserved \\
+\hline
+0x1 & VIRTIO_CRYPTO_IPSEC_MODE_ESP_TUNNEL & IPsec ESP protocol in tunnel mode \\
+\hline
+0x2 & VIRTIO_CRYPTO_IPSEC_MODE_ESP_TRANSPORT & IPsec ESP protocol in transport mode \\
+\hline
+0x3 & VIRTIO_CRYPTO_IPSEC_MODE_AH_TUNNEL & IPsec AH protocol in tunnel mode \\
+\hline
+0x4 & VIRTIO_CRYPTO_IPSEC_MODE_AH_TRANSPORT & IPsec AH protocol in transport mode \\
+\hline
+\end{tabularx}
+\end{table}
+
+\begin{table}[H]
+\caption{IPsec Options}
+\label{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}
+\begin{tabularx}{\textwidth}{ |l|X|X| }
+\hline
+Type & Name & Description \\
+\hline \hline
+0x0 & - & Reserved \\
+\hline
+0x1 & VIRTIO_CRYPTO_IPSEC_ESN & Specifies whether extended sequence number is supported \\
+\hline
+0x2 & VIRTIO_CRYPTO_IPSEC_UDP_ENCAP & Specifies whether udp encapsulation is supported \\
+\hline
+0x3 & VIRTIO_CRYPTO_IPSEC_COPY_DSCP & Specifies whether copy dscp is supported \\
+\hline
+0x4 & VIRTIO_CRYPTO_IPSEC_DEC_TTL & Specifies whether decrementing the time to live is supported \\
+\hline
+\end{tabularx}
+\end{table}
+
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH RFC 1/4] virtio-crypto: Add IPsec service operation and Capabilities
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
0 siblings, 1 reply; 11+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-12-05 12:04 UTC (permalink / raw)
To: Srujana Challa
Cc: virtio-comment, mst, cohuck, parav, sburla, ndabilpuram, jerinj,
anoobj
Hello,
I left some minor comments:
On Fri, Nov 15, 2024 at 05:15:20PM +0530, Srujana Challa wrote:
> This commit introduces the IPsec service operation to the Crypto
> device, enabling offloading of IPsec processing.
>
> Capabilities:
>
> 1. IPsec Resource Capability (VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP):
> Indicates the device's IPsec resource limits, such as the number of
> outbound and inbound Security Associations (SAs).
> 2. IPsec SA Capability (VIRTIO_CRYPTO_IPSEC_SA_CAP): Specifies the
> supported IPsec modes, along with the supported cryptographic
> algorithms, authentication algorithms, IPsec options and
> anti-replay window size.
>
> Signed-off-by: Srujana Challa <schalla@marvell.com>
> ---
> device-types/crypto/description.tex | 164 +++++++++++++++++++++++++++-
> 1 file changed, 159 insertions(+), 5 deletions(-)
>
> diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
> index 5705e26..ce4b1fb 100644
> --- a/device-types/crypto/description.tex
> +++ b/device-types/crypto/description.tex
> @@ -2,11 +2,11 @@ \section{Crypto Device}\label{sec:Device Types / Crypto Device}
>
> The virtio crypto device is a virtual cryptography device as well as a
> virtual cryptographic accelerator. The virtio crypto device provides the
> -following crypto services: CIPHER, MAC, HASH, AEAD and AKCIPHER. Virtio crypto
> -devices have a single control queue and at least one data queue. Crypto
> -operation requests are placed into a data queue, and serviced by the
> -device. Some crypto operation requests are only valid in the context of a
> -session. The role of the control queue is facilitating control operation
> +following crypto services: CIPHER, MAC, HASH, AEAD, AKCIPHER and IPSEC.
> +Virtio crypto devices have a single control queue and at least one data
> +queue. Crypto operation requests are placed into a data queue, and serviced
> +by the device. Some crypto operation requests are only valid in the context
> +of a session. The role of the control queue is facilitating control operation
> requests. Sessions management is realized with control operation
> requests.
>
> @@ -72,6 +72,8 @@ \subsection{Supported crypto services}\label{sec:Device Types / Crypto Device /
> #define VIRTIO_CRYPTO_SERVICE_AEAD 3
> /* AKCIPHER (Asymmetric Key Cipher) service */
> #define VIRTIO_CRYPTO_SERVICE_AKCIPHER 4
> +/* IPSEC service */
> +#define VIRTIO_CRYPTO_SERVICE_IPSEC 5
> \end{lstlisting}
>
> The above constants designate bits used to indicate the which of crypto services are
> @@ -318,6 +320,20 @@ \subsection{Device Initialization}\label{sec:Device Types / Crypto Device / Devi
> \item The driver MUST read the supported algorithms based on \field{crypto_services} field.
> \end{itemize*}
>
> +\subsection{Device and driver capabilities}\label{sec:Device Types / Crypto Device / Device and driver capabilities}
> +
> +The crypto device has the following capabilities.
> +
> +\begin{tabularx}{\textwidth}{ |l||l|X| }
> +\hline
> +Identifier & Name & Description \\
> +\hline \hline
> +0x0800 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-RESOURCE-CAP]{VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP} & IPsec resource capability \\
> +\hline
> +0x0801 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP]{VIRTIO_CRYPTO_IPSEC_SA_CAP} & IPsec Security Association(SA) capability \\
> +\hline
> +\end{tabularx}
> +
> \subsection{Device Operation}\label{sec:Device Types / Crypto Device / Device Operation}
>
> The operation of a virtio crypto device is driven by requests placed on the virtqueues.
> @@ -1872,3 +1888,141 @@ \subsubsection{AKCIPHER Service Operation}\label{sec:Device Types / Crypto Devic
> \item VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
> \end{itemize*}
> \end{itemize*}
> +
> +\subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device / Device Operation / IPSEC Service Operation}
> +
> +A crypto device can support the programming of IPsec Security Associations(SAs).
> +In addition to standard crypto processing, the IPsec protocol processing is
> +also offloaded to the Crypto Device as lookaside operation.
> +
> +IPsec Inbound processing: The device will perform decryption, authentication,
> +integrity checking and remove additional headers, including tunnel headers if
> +in tunnel mode, as well as the ESP/AH header from the packet. The resulting
> +packet contains only the plain data.
> +
> +IPsec Outbound processing: The device will perform encryption, attach ICV,
> +update/add IP headers, add ESP/AH headers/trailers.
> +
> +A crypto device can support number of IPsec SAs, allowing it to manage multiple secure
> +connections simultaneously.
> +
> +The device and the driver indicates IPsec SA resource limits using the capability
s/indicates/indicate
> +VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP specifying the limits on the number of IPsec outbound and
> +inbound SA resource objects.
> +The capability VIRTIO_CRYPTO_IPSEC_SA_CAP specifies which IPsec protocol capabilities
> +the device supports. The driver indicates the IPsec parameters(Crypto algorithm,
> +IPsec mode, anti-replay window size, etc.) it is using by setting the IPsec SA capability,
> +prior to adding any resource objects.
> +
I think you mean:
`The driver indicates the IPsec parameters by setting the IPsec SA
capability prior to adding any resource objects`.
> +The driver controls the IPsec SA resource objects using administration commands described in
> +\ref{sec:Basic Facilities of a Virtio Device / Device groups / Group administration commands / Device resource objects}.
> +
> +\paragraph{Device and driver capabilities}
> +\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities}
> +
> +\subparagraph{VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP}
> +\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-RESOURCE-CAP}
> +
> +The capability VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP indicates the IPsec SA resource limits.
> +\field{cap_specific_data} is in the format
> +\field{struct virtio_crypto_ipsec_resource_cap}.
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ipsec_resource_cap {
> + le32 inb_sa_limit;
> + le32 outb_sa_limit;
> +};
> +\end{lstlisting}
> +
> +\field{inb_sa_limit}, and \field{outb_sa_limit} denote the maximum number of IPsec
> +security Associations (SAs) that can be utilized for IPsec inbound and outbound processing,
> +respectively, which the device is capable of creating.
> +
> +\subparagraph{VIRTIO_CRYPTO_IPSEC_SA_CAP}
> +\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP}
> +
> +The capability VIRTIO_CRYPTO_IPSEC_SA_CAP lists the supported IPsec modes along with
I think here `capability` goes after `VIRTIO_CRYPTO_IPSEC_SA_CAP`. I
think this also applies to cases above.
> +the supported cryptographic, authentication algorithms and anti-replay window size for
> +each IPsec mode.
> +\field{cap_specific_data} is in the format \field{struct virtio_crypto_ipsec_sa_cap_data}.
> +
> +\begin{lstlisting}[label={lst:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / virtio-crypto-ipsec-mode-cap}]
> +struct virtio_crypto_ipsec_mode_cap {
> + le32 replay_win_sz_max;
> + le32 options;
> + le64 cipher_algo;
> + le64 hmac_algo;
> + le32 aead_algo;
> + le32 max_cipher_key_len;
> + le32 max_auth_key_len;
> + u8 mode;
> + u8 padding[3];
> +};
> +
> +struct virtio_crypto_ipsec_sa_cap_data {
> + u8 count;
> + u8 reserved[7];
> + struct virtio_crypto_ipsec_mode_cap mode[];
> +};
> +\end{lstlisting}
> +
> +\field{count} indicates number of valid entries in the \field{mode} array.
> +\field{mode[]} is an array of supported IPsec modes. Within each array entry:
> +
> +\field{mode} specifies the IPsec mode, as defined in table
> +\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}.
> +\field{replay_win_sz_max} specifies the maximum anti-replay window size the device supports.
> +
> +\field{options} represents the IPsec protocol options the device supports, as defined in table
> +\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}.
> +
> +\field{cipher_algo} CIPHER algorithms mask, see \ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}.
> +
> +\field{hmac_algo} HMAC algorithms mask, see \ref{sec:Device Types / Crypto Device / Supported crypto services / MAC services}.
> +
> +\field{aead_algo} AEAD algorithms mask, see \ref{sec:Device Types / Crypto Device / Supported crypto services / AEAD services}.
> +
> +\field{max_cipher_key_len} is the maximum length of cipher key supported by the device.
> +
> +\field{max_auth_key_len} is the maximum length of authenticated key supported by the device.
> +
> +\begin{table}[H]
> +\caption{IPsec Modes}
> +\label{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}
> +\begin{tabularx}{\textwidth}{ |l|X|X| }
> +\hline
> +Type & Name & Description \\
> +\hline \hline
> +0x0 & - & Reserved \\
> +\hline
> +0x1 & VIRTIO_CRYPTO_IPSEC_MODE_ESP_TUNNEL & IPsec ESP protocol in tunnel mode \\
> +\hline
> +0x2 & VIRTIO_CRYPTO_IPSEC_MODE_ESP_TRANSPORT & IPsec ESP protocol in transport mode \\
> +\hline
> +0x3 & VIRTIO_CRYPTO_IPSEC_MODE_AH_TUNNEL & IPsec AH protocol in tunnel mode \\
> +\hline
> +0x4 & VIRTIO_CRYPTO_IPSEC_MODE_AH_TRANSPORT & IPsec AH protocol in transport mode \\
> +\hline
> +\end{tabularx}
> +\end{table}
> +
> +\begin{table}[H]
> +\caption{IPsec Options}
> +\label{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}
> +\begin{tabularx}{\textwidth}{ |l|X|X| }
> +\hline
> +Type & Name & Description \\
> +\hline \hline
> +0x0 & - & Reserved \\
> +\hline
> +0x1 & VIRTIO_CRYPTO_IPSEC_ESN & Specifies whether extended sequence number is supported \\
> +\hline
> +0x2 & VIRTIO_CRYPTO_IPSEC_UDP_ENCAP & Specifies whether udp encapsulation is supported \\
> +\hline
> +0x3 & VIRTIO_CRYPTO_IPSEC_COPY_DSCP & Specifies whether copy dscp is supported \\
> +\hline
> +0x4 & VIRTIO_CRYPTO_IPSEC_DEC_TTL & Specifies whether decrementing the time to live is supported \\
> +\hline
> +\end{tabularx}
> +\end{table}
> +
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread* RE: [EXTERNAL] Re: [PATCH RFC 1/4] virtio-crypto: Add IPsec service operation and Capabilities
2024-12-05 12:04 ` Matias Ezequiel Vara Larsen
@ 2024-12-06 7:05 ` Srujana Challa
0 siblings, 0 replies; 11+ messages in thread
From: Srujana Challa @ 2024-12-06 7:05 UTC (permalink / raw)
To: Matias Ezequiel Vara Larsen
Cc: virtio-comment@lists.linux.dev, mst@redhat.com, cohuck@redhat.com,
parav@nvidia.com, Satananda Burla, Nithin Kumar Dabilpuram,
Jerin Jacob, Anoob Joseph
> Hello,
>
> I left some minor comments:
>
> On Fri, Nov 15, 2024 at 05:15:20PM +0530, Srujana Challa wrote:
> > This commit introduces the IPsec service operation to the Crypto
> > device, enabling offloading of IPsec processing.
> >
> > Capabilities:
> >
> > 1. IPsec Resource Capability (VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP):
> > Indicates the device's IPsec resource limits, such as the number of
> > outbound and inbound Security Associations (SAs).
> > 2. IPsec SA Capability (VIRTIO_CRYPTO_IPSEC_SA_CAP): Specifies the
> > supported IPsec modes, along with the supported cryptographic
> > algorithms, authentication algorithms, IPsec options and
> > anti-replay window size.
> >
> > Signed-off-by: Srujana Challa <schalla@marvell.com>
> > ---
> > device-types/crypto/description.tex | 164
> > +++++++++++++++++++++++++++-
> > 1 file changed, 159 insertions(+), 5 deletions(-)
> >
> > diff --git a/device-types/crypto/description.tex
> > b/device-types/crypto/description.tex
> > index 5705e26..ce4b1fb 100644
> > --- a/device-types/crypto/description.tex
> > +++ b/device-types/crypto/description.tex
> > @@ -2,11 +2,11 @@ \section{Crypto Device}\label{sec:Device Types /
> > Crypto Device}
> >
> > The virtio crypto device is a virtual cryptography device as well as
> > a virtual cryptographic accelerator. The virtio crypto device
> > provides the -following crypto services: CIPHER, MAC, HASH, AEAD and
> > AKCIPHER. Virtio crypto -devices have a single control queue and at
> > least one data queue. Crypto -operation requests are placed into a
> > data queue, and serviced by the -device. Some crypto operation
> > requests are only valid in the context of a -session. The role of the
> > control queue is facilitating control operation
> > +following crypto services: CIPHER, MAC, HASH, AEAD, AKCIPHER and IPSEC.
> > +Virtio crypto devices have a single control queue and at least one
> > +data queue. Crypto operation requests are placed into a data queue,
> > +and serviced by the device. Some crypto operation requests are only
> > +valid in the context of a session. The role of the control queue is
> > +facilitating control operation
> > requests. Sessions management is realized with control operation
> > requests.
> >
> > @@ -72,6 +72,8 @@ \subsection{Supported crypto
> services}\label{sec:Device Types / Crypto Device /
> > #define VIRTIO_CRYPTO_SERVICE_AEAD 3
> > /* AKCIPHER (Asymmetric Key Cipher) service */ #define
> > VIRTIO_CRYPTO_SERVICE_AKCIPHER 4
> > +/* IPSEC service */
> > +#define VIRTIO_CRYPTO_SERVICE_IPSEC 5
> > \end{lstlisting}
> >
> > The above constants designate bits used to indicate the which of
> > crypto services are @@ -318,6 +320,20 @@ \subsection{Device
> > Initialization}\label{sec:Device Types / Crypto Device / Devi \item The driver
> MUST read the supported algorithms based on \field{crypto_services} field.
> > \end{itemize*}
> >
> > +\subsection{Device and driver capabilities}\label{sec:Device Types /
> > +Crypto Device / Device and driver capabilities}
> > +
> > +The crypto device has the following capabilities.
> > +
> > +\begin{tabularx}{\textwidth}{ |l||l|X| } \hline Identifier & Name &
> > +Description \\ \hline \hline
> > +0x0800 & \hyperref[par:Device Types / Crypto Device / Device
> > +Operation / IPsec Service Operation / Device and driver capabilities
> > +/ VIRTIO-CRYPTO-IPSEC-RESOURCE-
> CAP]{VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP}
> > +& IPsec resource capability \\ \hline
> > +0x0801 & \hyperref[par:Device Types / Crypto Device / Device
> > +Operation / IPsec Service Operation / Device and driver capabilities
> > +/ VIRTIO-CRYPTO-IPSEC-SA-CAP]{VIRTIO_CRYPTO_IPSEC_SA_CAP} & IPsec
> > +Security Association(SA) capability \\ \hline \end{tabularx}
> > +
> > \subsection{Device Operation}\label{sec:Device Types / Crypto Device
> > / Device Operation}
> >
> > The operation of a virtio crypto device is driven by requests placed on the
> virtqueues.
> > @@ -1872,3 +1888,141 @@ \subsubsection{AKCIPHER Service
> > Operation}\label{sec:Device Types / Crypto Devic \item
> VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
> > \end{itemize*}
> > \end{itemize*}
> > +
> > +\subsubsection{IPSEC Service Operation}\label{sec:Device Types /
> > +Crypto Device / Device Operation / IPSEC Service Operation}
> > +
> > +A crypto device can support the programming of IPsec Security
> Associations(SAs).
> > +In addition to standard crypto processing, the IPsec protocol
> > +processing is also offloaded to the Crypto Device as lookaside operation.
> > +
> > +IPsec Inbound processing: The device will perform decryption,
> > +authentication, integrity checking and remove additional headers,
> > +including tunnel headers if in tunnel mode, as well as the ESP/AH
> > +header from the packet. The resulting packet contains only the plain data.
> > +
> > +IPsec Outbound processing: The device will perform encryption, attach
> > +ICV, update/add IP headers, add ESP/AH headers/trailers.
> > +
> > +A crypto device can support number of IPsec SAs, allowing it to
> > +manage multiple secure connections simultaneously.
> > +
> > +The device and the driver indicates IPsec SA resource limits using
> > +the capability
>
> s/indicates/indicate
>
> > +VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP specifying the limits on the
> number
> > +of IPsec outbound and inbound SA resource objects.
> > +The capability VIRTIO_CRYPTO_IPSEC_SA_CAP specifies which IPsec
> > +protocol capabilities the device supports. The driver indicates the
> > +IPsec parameters(Crypto algorithm, IPsec mode, anti-replay window
> > +size, etc.) it is using by setting the IPsec SA capability, prior to adding any
> resource objects.
> > +
>
> I think you mean:
> `The driver indicates the IPsec parameters by setting the IPsec SA capability
> prior to adding any resource objects`.
>
> > +The driver controls the IPsec SA resource objects using
> > +administration commands described in \ref{sec:Basic Facilities of a Virtio
> Device / Device groups / Group administration commands / Device resource
> objects}.
> > +
> > +\paragraph{Device and driver capabilities} \label{par:Device Types /
> > +Crypto Device / Device Operation / IPsec Service Operation / Device
> > +and driver capabilities}
> > +
> > +\subparagraph{VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP}
> > +\label{par:Device Types / Crypto Device / Device Operation / IPsec
> > +Service Operation / Device and driver capabilities /
> > +VIRTIO-CRYPTO-IPSEC-RESOURCE-CAP}
> > +
> > +The capability VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP indicates the IPsec
> SA resource limits.
> > +\field{cap_specific_data} is in the format \field{struct
> > +virtio_crypto_ipsec_resource_cap}.
> > +
> > +\begin{lstlisting}
> > +struct virtio_crypto_ipsec_resource_cap {
> > + le32 inb_sa_limit;
> > + le32 outb_sa_limit;
> > +};
> > +\end{lstlisting}
> > +
> > +\field{inb_sa_limit}, and \field{outb_sa_limit} denote the maximum
> > +number of IPsec security Associations (SAs) that can be utilized for
> > +IPsec inbound and outbound processing, respectively, which the device is
> capable of creating.
> > +
> > +\subparagraph{VIRTIO_CRYPTO_IPSEC_SA_CAP}
> > +\label{par:Device Types / Crypto Device / Device Operation / IPsec
> > +Service Operation / Device and driver capabilities /
> > +VIRTIO-CRYPTO-IPSEC-SA-CAP}
> > +
> > +The capability VIRTIO_CRYPTO_IPSEC_SA_CAP lists the supported IPsec
> > +modes along with
>
> I think here `capability` goes after `VIRTIO_CRYPTO_IPSEC_SA_CAP`. I think
> this also applies to cases above.
>
> > +the supported cryptographic, authentication algorithms and
> > +anti-replay window size for each IPsec mode.
> > +\field{cap_specific_data} is in the format \field{struct
> virtio_crypto_ipsec_sa_cap_data}.
> > +
> > +\begin{lstlisting}[label={lst:Device Types / Crypto Device / Device
> > +Operation / IPsec Service Operation / Device and driver capabilities /
> VIRTIO-CRYPTO-IPSEC-SA-CAP / virtio-crypto-ipsec-mode-cap}] struct
> virtio_crypto_ipsec_mode_cap {
> > + le32 replay_win_sz_max;
> > + le32 options;
> > + le64 cipher_algo;
> > + le64 hmac_algo;
> > + le32 aead_algo;
> > + le32 max_cipher_key_len;
> > + le32 max_auth_key_len;
> > + u8 mode;
> > + u8 padding[3];
> > +};
> > +
> > +struct virtio_crypto_ipsec_sa_cap_data {
> > + u8 count;
> > + u8 reserved[7];
> > + struct virtio_crypto_ipsec_mode_cap mode[]; };
> > +\end{lstlisting}
> > +
> > +\field{count} indicates number of valid entries in the \field{mode} array.
> > +\field{mode[]} is an array of supported IPsec modes. Within each array
> entry:
> > +
> > +\field{mode} specifies the IPsec mode, as defined in table
> > +\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service
> Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP /
> IPsec Modes}.
> > +\field{replay_win_sz_max} specifies the maximum anti-replay window size
> the device supports.
> > +
> > +\field{options} represents the IPsec protocol options the device
> > +supports, as defined in table \ref{table:Device Types / Crypto Device /
> Device Operation / IPsec Service Operation / Device and driver capabilities /
> VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}.
> > +
> > +\field{cipher_algo} CIPHER algorithms mask, see \ref{sec:Device Types /
> Crypto Device / Supported crypto services / CIPHER services}.
> > +
> > +\field{hmac_algo} HMAC algorithms mask, see \ref{sec:Device Types /
> Crypto Device / Supported crypto services / MAC services}.
> > +
> > +\field{aead_algo} AEAD algorithms mask, see \ref{sec:Device Types / Crypto
> Device / Supported crypto services / AEAD services}.
> > +
> > +\field{max_cipher_key_len} is the maximum length of cipher key supported
> by the device.
> > +
> > +\field{max_auth_key_len} is the maximum length of authenticated key
> supported by the device.
> > +
> > +\begin{table}[H]
> > +\caption{IPsec Modes}
> > +\label{table:Device Types / Crypto Device / Device Operation / IPsec
> > +Service Operation / Device and driver capabilities /
> > +VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}
> > +\begin{tabularx}{\textwidth}{ |l|X|X| } \hline Type & Name &
> > +Description \\ \hline \hline
> > +0x0 & - & Reserved \\
> > +\hline
> > +0x1 & VIRTIO_CRYPTO_IPSEC_MODE_ESP_TUNNEL & IPsec ESP protocol in
> > +tunnel mode \\ \hline
> > +0x2 & VIRTIO_CRYPTO_IPSEC_MODE_ESP_TRANSPORT & IPsec ESP
> protocol in
> > +transport mode \\ \hline
> > +0x3 & VIRTIO_CRYPTO_IPSEC_MODE_AH_TUNNEL & IPsec AH protocol in
> > +tunnel mode \\ \hline
> > +0x4 & VIRTIO_CRYPTO_IPSEC_MODE_AH_TRANSPORT & IPsec AH protocol
> in
> > +transport mode \\ \hline \end{tabularx} \end{table}
> > +
> > +\begin{table}[H]
> > +\caption{IPsec Options}
> > +\label{table:Device Types / Crypto Device / Device Operation / IPsec
> > +Service Operation / Device and driver capabilities /
> > +VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}
> > +\begin{tabularx}{\textwidth}{ |l|X|X| } \hline Type & Name &
> > +Description \\ \hline \hline
> > +0x0 & - & Reserved \\
> > +\hline
> > +0x1 & VIRTIO_CRYPTO_IPSEC_ESN & Specifies whether extended sequence
> > +number is supported \\ \hline
> > +0x2 & VIRTIO_CRYPTO_IPSEC_UDP_ENCAP & Specifies whether udp
> > +encapsulation is supported \\ \hline
> > +0x3 & VIRTIO_CRYPTO_IPSEC_COPY_DSCP & Specifies whether copy dscp is
> > +supported \\ \hline
> > +0x4 & VIRTIO_CRYPTO_IPSEC_DEC_TTL & Specifies whether decrementing
> > +the time to live is supported \\ \hline \end{tabularx} \end{table}
> > +
> > --
> > 2.25.1
> >
> >
Thank you for reviewing the patches. I will address the comments and send
the revised version shortly.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH RFC 2/4] virtio-crypto: Add resource objects for IPsec outbound and inbound SAs
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-11-15 11:45 ` 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
` (2 subsequent siblings)
4 siblings, 1 reply; 11+ messages in thread
From: Srujana Challa @ 2024-11-15 11:45 UTC (permalink / raw)
To: virtio-comment
Cc: mst, cohuck, parav, sburla, ndabilpuram, jerinj, anoobj, schalla
This commit introduces resource objects to enable the driver/device to
create IPsec Security Associations (SAs) for both inbound and outbound
directions.
The IPsec SA objects include essential parameters required for packet
outbound and inbound processing, such as SPI, tunnel headers, IPsec mode,
IPsec options and cipher/authentication specific data.
Signed-off-by: Srujana Challa <schalla@marvell.com>
---
device-types/crypto/description.tex | 133 ++++++++++++++++++++++++++++
1 file changed, 133 insertions(+)
diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
index ce4b1fb..7ac6f5b 100644
--- a/device-types/crypto/description.tex
+++ b/device-types/crypto/description.tex
@@ -334,6 +334,20 @@ \subsection{Device and driver capabilities}\label{sec:Device Types / Crypto Devi
\hline
\end{tabularx}
+\subsection{Device resource objects}\label{sec:Device Types / Crypto Device / Device resource objects}
+
+The crypto device has the following resource objects.
+
+\begin{tabularx}{\textwidth}{ |l||l|X| }
+\hline
+type & Name & Description \\
+\hline \hline
+0x0200 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA]{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA} & IPsec outbound SA resource object \\
+\hline
+0x0201 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-INBOUND-SA]{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA} & IPsec inbound SA resource object \\
+\hline
+\end{tabularx}
+
\subsection{Device Operation}\label{sec:Device Types / Crypto Device / Device Operation}
The operation of a virtio crypto device is driven by requests placed on the virtqueues.
@@ -2026,3 +2040,122 @@ \subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device /
\end{tabularx}
\end{table}
+\paragraph{Resource objects}
+\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects}
+
+\subparagraph{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA}\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA}
+
+A driver can have outbound SAs between 0 and \field{outb_sa_limit}, as specified by the
+capability VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP. For the IPsec outbound SA resource object
+\field{resource_obj_specific_data} is in the format
+\field{struct virtio_crypto_resource_obj_ipsec_sa}.
+
+\begin{lstlisting}
+struct virtio_crypto_ipsec_tunnel_param {
+ /* Tunnel type: IPv4 or IPv6 */
+ u8 type;
+ u8 reserved[3];
+ union {
+ /* IPv4 tunnel header parameters */
+ struct {
+ /* IPv4 source address */
+ struct in_addr src_ip;
+ /* IPv4 destination address */
+ struct in_addr dst_ip;
+ /* IPv4 Differentiated Services Code Point */
+ uint8_t dscp;
+ /* IPv4 Don't Fragment bit */
+ uint8_t df;
+ /* IPv4 Time To Live */
+ uint8_t ttl;
+ } ipv4;
+ /* IPv6 tunnel header parameters */
+ struct {
+ /* IPv6 source address */
+ struct in6_addr src_addr;
+ /* IPv6 destination address */
+ struct in6_addr dst_addr;
+ /* IPv6 flow label */
+ uint32_t flabel;
+ /* IPv6 hop limit */
+ uint8_t hlimit;
+ /* IPv6 Differentiated Services Code Point */
+ uint8_t dscp;
+ } ipv6;
+ };
+};
+
+struct virtio_crypto_resource_obj_ipsec_sa {
+ le32 spi;
+ le32 salt;
+ le64 options;
+ struct virtio_crypto_ipsec_tunnel_param param;
+ le64 esn;
+ le16 udp_sport;
+ le16 udp_dport;
+ le32 replay_win_sz;
+ le64 cipher_algo;
+ struct {
+ u8 *data;
+ le16 length;
+ } cipher_key;
+ le64 auth_algo;
+ struct {
+ u8 *data;
+ le16 length;
+ } auth_key;
+ le32 obj_id;
+ u8 mode;
+ u8 direction;
+}
+\end{lstlisting}
+
+\field{spi} is the Security Parameter Index(SPI) used to uniquely identify the IPsec SA.
+\field{salt} is the 32 bit salt value used in the cryptographic operations.
+
+\field{options} specifies the Options for configuring the IPsec SA, see
+\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}.
+
+\field{param} specifies the parameters for IPsec tunnel mode.
+\field{esn} is the starting sequence number.
+\field{udp_sport} is the source port for UDP encapsulation. \field{udp_dport} is the
+destination port for UDP encapsulation.
+\field{replay_win_sz} is the anti-replay window size to enable sequence replay attack
+handling, replay checking is disabled if the window size is 0.
+
+\field{cipher_algo} is the cipher algorithm identifier
+see \ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}
+\field{cipher_key} specifies the cipher key and it's length.
+\field{auth_algo} is the Authentication algorithm identifier
+\field{auth_key} specifies the authentication key data and its length.
+\field{obj_id} specifies the object id of the SA that can be used to retrieve
+driver-defined data associated with the IPsec SA.
+
+\field{mode} specifies the mode of the IPsec SA, see
+\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}.
+
+\field{direction} specifies IPsec SA direction, see
+\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA / IPsec Direction}.
+
+\begin{table}[H]
+\caption{IPsec Direction}
+\label{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA / IPsec Direction}
+\begin{tabularx}{\textwidth}{ |l|X|X| }
+\hline
+Type & Name & Description \\
+\hline \hline
+0x0 & - & Reserved \\
+\hline
+0x1 & VIRTIO_CRYPTO_IPSEC_DIR_OUTBOUND & IPsec direction outbound \\
+\hline
+0x2 & VIRTIO_CRYPTO_IPSEC_DIR_INBOUND & IPsec direction inbound \\
+\hline
+\end{tabularx}
+\end{table}
+
+\subparagraph{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA}\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-INBOUND-SA}
+
+A driver can have inbound SAs between 0 and \field{inb_sa_limit}, as specified by the
+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}.
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH RFC 2/4] virtio-crypto: Add resource objects for IPsec outbound and inbound SAs
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
0 siblings, 0 replies; 11+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-12-07 12:24 UTC (permalink / raw)
To: Srujana Challa
Cc: virtio-comment, mst, cohuck, parav, sburla, ndabilpuram, jerinj,
anoobj
On Fri, Nov 15, 2024 at 05:15:21PM +0530, Srujana Challa wrote:
> This commit introduces resource objects to enable the driver/device to
> create IPsec Security Associations (SAs) for both inbound and outbound
> directions.
>
> The IPsec SA objects include essential parameters required for packet
> outbound and inbound processing, such as SPI, tunnel headers, IPsec mode,
> IPsec options and cipher/authentication specific data.
>
> Signed-off-by: Srujana Challa <schalla@marvell.com>
> ---
> device-types/crypto/description.tex | 133 ++++++++++++++++++++++++++++
> 1 file changed, 133 insertions(+)
>
> diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
> index ce4b1fb..7ac6f5b 100644
> --- a/device-types/crypto/description.tex
> +++ b/device-types/crypto/description.tex
> @@ -334,6 +334,20 @@ \subsection{Device and driver capabilities}\label{sec:Device Types / Crypto Devi
> \hline
> \end{tabularx}
>
> +\subsection{Device resource objects}\label{sec:Device Types / Crypto Device / Device resource objects}
> +
> +The crypto device has the following resource objects.
> +
> +\begin{tabularx}{\textwidth}{ |l||l|X| }
> +\hline
> +type & Name & Description \\
> +\hline \hline
> +0x0200 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA]{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA} & IPsec outbound SA resource object \\
> +\hline
> +0x0201 & \hyperref[par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-INBOUND-SA]{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA} & IPsec inbound SA resource object \\
> +\hline
> +\end{tabularx}
> +
> \subsection{Device Operation}\label{sec:Device Types / Crypto Device / Device Operation}
>
> The operation of a virtio crypto device is driven by requests placed on the virtqueues.
> @@ -2026,3 +2040,122 @@ \subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device /
> \end{tabularx}
> \end{table}
>
> +\paragraph{Resource objects}
> +\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects}
> +
> +\subparagraph{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA}\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA}
> +
> +A driver can have outbound SAs between 0 and \field{outb_sa_limit}, as specified by the
> +capability VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP. For the IPsec outbound SA resource object
> +\field{resource_obj_specific_data} is in the format
> +\field{struct virtio_crypto_resource_obj_ipsec_sa}.
> +
> +\begin{lstlisting}
> +struct virtio_crypto_ipsec_tunnel_param {
> + /* Tunnel type: IPv4 or IPv6 */
> + u8 type;
> + u8 reserved[3];
> + union {
> + /* IPv4 tunnel header parameters */
> + struct {
> + /* IPv4 source address */
> + struct in_addr src_ip;
> + /* IPv4 destination address */
> + struct in_addr dst_ip;
> + /* IPv4 Differentiated Services Code Point */
> + uint8_t dscp;
> + /* IPv4 Don't Fragment bit */
> + uint8_t df;
> + /* IPv4 Time To Live */
> + uint8_t ttl;
> + } ipv4;
> + /* IPv6 tunnel header parameters */
> + struct {
> + /* IPv6 source address */
> + struct in6_addr src_addr;
> + /* IPv6 destination address */
> + struct in6_addr dst_addr;
> + /* IPv6 flow label */
> + uint32_t flabel;
> + /* IPv6 hop limit */
> + uint8_t hlimit;
> + /* IPv6 Differentiated Services Code Point */
> + uint8_t dscp;
> + } ipv6;
> + };
> +};
> +
> +struct virtio_crypto_resource_obj_ipsec_sa {
> + le32 spi;
> + le32 salt;
> + le64 options;
> + struct virtio_crypto_ipsec_tunnel_param param;
> + le64 esn;
> + le16 udp_sport;
> + le16 udp_dport;
> + le32 replay_win_sz;
> + le64 cipher_algo;
> + struct {
> + u8 *data;
> + le16 length;
> + } cipher_key;
> + le64 auth_algo;
> + struct {
> + u8 *data;
> + le16 length;
> + } auth_key;
> + le32 obj_id;
> + u8 mode;
> + u8 direction;
> +}
> +\end{lstlisting}
> +
> +\field{spi} is the Security Parameter Index(SPI) used to uniquely identify the IPsec SA.
> +\field{salt} is the 32 bit salt value used in the cryptographic operations.
> +
> +\field{options} specifies the Options for configuring the IPsec SA, see
> +\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Options}.
> +
> +\field{param} specifies the parameters for IPsec tunnel mode.
> +\field{esn} is the starting sequence number.
> +\field{udp_sport} is the source port for UDP encapsulation. \field{udp_dport} is the
> +destination port for UDP encapsulation.
> +\field{replay_win_sz} is the anti-replay window size to enable sequence replay attack
> +handling, replay checking is disabled if the window size is 0.
> +
> +\field{cipher_algo} is the cipher algorithm identifier
> +see \ref{sec:Device Types / Crypto Device / Supported crypto services / CIPHER services}
> +\field{cipher_key} specifies the cipher key and it's length.
s/it's/its
> +\field{auth_algo} is the Authentication algorithm identifier
> +\field{auth_key} specifies the authentication key data and its length.
> +\field{obj_id} specifies the object id of the SA that can be used to retrieve
> +driver-defined data associated with the IPsec SA.
> +
> +\field{mode} specifies the mode of the IPsec SA, see
> +\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-IPSEC-SA-CAP / IPsec Modes}.
> +
> +\field{direction} specifies IPsec SA direction, see
> +\ref{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA / IPsec Direction}.
> +
> +\begin{table}[H]
> +\caption{IPsec Direction}
> +\label{table:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Device and driver capabilities / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-OUTBOUND-SA / IPsec Direction}
> +\begin{tabularx}{\textwidth}{ |l|X|X| }
> +\hline
> +Type & Name & Description \\
> +\hline \hline
> +0x0 & - & Reserved \\
> +\hline
> +0x1 & VIRTIO_CRYPTO_IPSEC_DIR_OUTBOUND & IPsec direction outbound \\
> +\hline
> +0x2 & VIRTIO_CRYPTO_IPSEC_DIR_INBOUND & IPsec direction inbound \\
> +\hline
> +\end{tabularx}
> +\end{table}
> +
> +\subparagraph{VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA}\label{par:Device Types / Crypto Device / Device Operation / IPsec Service Operation / Resource objects / VIRTIO-CRYPTO-RESOURCE-OBJ-IPSEC-INBOUND-SA}
> +
> +A driver can have inbound SAs between 0 and \field{inb_sa_limit}, as specified by the
> +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}.
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH RFC 3/4] virtio-crypto: Add new IPsec opcodes to data request
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-11-15 11:45 ` [PATCH RFC 2/4] virtio-crypto: Add resource objects for IPsec outbound and inbound SAs Srujana Challa
@ 2024-11-15 11:45 ` Srujana Challa
2024-12-12 9:46 ` Matias Ezequiel Vara Larsen
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:19 ` [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto Matias Ezequiel Vara Larsen
4 siblings, 1 reply; 11+ messages in thread
From: Srujana Challa @ 2024-11-15 11:45 UTC (permalink / raw)
To: virtio-comment
Cc: mst, cohuck, parav, sburla, ndabilpuram, jerinj, anoobj, schalla
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>
---
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH RFC 3/4] virtio-crypto: Add new IPsec opcodes to data request
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
0 siblings, 0 replies; 11+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-12-12 9:46 UTC (permalink / raw)
To: Srujana Challa
Cc: virtio-comment, mst, cohuck, parav, sburla, ndabilpuram, jerinj,
anoobj
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
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH RFC 4/4] virtio-crypto: Add device and driver requirements for IPsec operation
2024-11-15 11:45 [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto Srujana Challa
` (2 preceding siblings ...)
2024-11-15 11:45 ` [PATCH RFC 3/4] virtio-crypto: Add new IPsec opcodes to data request Srujana Challa
@ 2024-11-15 11:45 ` 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
4 siblings, 1 reply; 11+ messages in thread
From: Srujana Challa @ 2024-11-15 11:45 UTC (permalink / raw)
To: virtio-comment
Cc: mst, cohuck, parav, sburla, ndabilpuram, jerinj, anoobj, schalla
Add device and driver requirements for IPsec Operation.
Signed-off-by: Srujana Challa <schalla@marvell.com>
---
device-types/crypto/description.tex | 100 +++++++++++++++++++++
device-types/crypto/device-conformance.tex | 1 +
device-types/crypto/driver-conformance.tex | 1 +
3 files changed, 102 insertions(+)
diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
index 9c878f7..5ca6602 100644
--- a/device-types/crypto/description.tex
+++ b/device-types/crypto/description.tex
@@ -2238,3 +2238,103 @@ \subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device /
\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.
+
+\devicenormative{\paragraph}{IPsec Service Operation}{Device Types / Crypto Device / Device Operation / IPsec Service Operation}
+
+When the device supports IPsec operations,
+\begin{itemize}
+\item the device MUST set VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP, VIRTIO_CRYPTO_IPSEC_SA_CAP
+capability in the \field{supported_caps} in the command VIRTIO_ADMIN_CMD_CAP_SUPPORT_QUERY.
+\item the device MUST support the administration commands
+VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE,
+VIRTIO_ADMIN_CMD_RESOURCE_OBJ_MODIFY, VIRTIO_ADMIN_CMD_RESOURCE_OBJ_QUERY,
+VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY for the resource types
+VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA and VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA.
+\end{itemize}
+
+When any of the VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP or VIRTIO_CRYPTO_IPSEC_SA_CAP
+capability is disabled, the device MUST set \field{status} to
+VIRTIO_ADMIN_STATUS_Q_INVALID_OPCODE for the commands
+VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE,
+VIRTIO_ADMIN_CMD_RESOURCE_OBJ_MODIFY, VIRTIO_ADMIN_CMD_RESOURCE_OBJ_QUERY,
+and VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY.
+
+The device MUST set \field{status} to VIRTIO_ADMIN_STATUS_EEXIST for the
+command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE when the resource \field{type}
+is VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA,
+if the object is already exists with the supplied \field{id}.
+
+The device MUST set \field{status} to VIRTIO_ADMIN_STATUS_EBUSY for the
+command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY when the resource \field{type}
+is VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA,
+if the object is in use.
+
+The device MUST fail the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE with
+the \field{status} set to VIRTIO_ADMIN_STATUS_EINVAL, for the
+VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA object if,
+\begin{itemize}
+\item \field{id} is greater than or equal to \field{outb_sa_limit}.
+\item the supplied SA parameters, such as mode, options, cipher and authentication
+ algorithms is not supported in the capabitlity VIRTIO_CRYPTO_IPSEC_SA_CAP.
+\end{itemize}
+
+The device MUST fail the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE with
+the \field{status} set to VIRTIO_ADMIN_STATUS_EINVAL, for the
+VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA object if,
+\begin{itemize}
+\item \field{id} is greater than or equal to \field{inb_sa_limit}.
+\item the supplied SA parameters, such as mode, options, cipher and authentication
+ algorithms is not supported in the capabitlity VIRTIO_CRYPTO_IPSEC_SA_CAP.
+\end{itemize}
+
+The device SHOULD maintain a table for subsequent lookups for inbound/outbound data
+processing with the corresponding SA based on the supplied \field{id}.
+
+The device MUST allow recreating the resource objects using the command
+VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE which was previously destroyed using
+the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY respectively without
+undergoing a device reset.
+
+The device MAY fail the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE with
+the \field{status} set to VIRTIO_ADMIN_STATUS_EINVAL for the
+VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA
+commands if the resource object with the same \field{spi} already exists.
+
+On device reset, the device MUST destroy all the resource objects which have been created.
+
+The device MUST copy the result of IPsec operation in the \field{dst_data[]}.
+The device MUST set the \field{status} field in struct virtio_crypto_inhdr to
+one of the following values of enum VIRTIO_CRYPTO_STATUS:
+\begin{itemize*}
+\item VIRTIO_CRYPTO_OK if the operation success.
+\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operation is unsupported.
+\item VIRTIO_CRYPTO_BADMSG if the integrity check is failed for IPsec decryption.
+\item VIRTIO_CRYPTO_INVSESS if the session ID invalid.
+\item VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
+\end{itemize*}
+
+\drivernormative{\paragraph}{IPsec Service Operation}{Device Types / Crypto Device / Device Operation / IPsec Service Operation}
+
+The driver MUST query the capabilities using VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY
+to discover the capability types the device offers.
+
+The driver MUST get VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP and VIRTIO_CRYPTO_IPSEC_SA_CAP
+if listed in VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY command result, using
+VIRTION_ADMIN_CMD_DEVICE_CAP_GET to discover the capabilities the device is
+able to offer.
+The driver MUST set VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP and VIRTIO_CRYPTO_IPSEC_SA_CAP
+using VIRTIO_ADMIN_CMD_DEVICE_CAP_SET to indicate the device which capability
+the driver uses.
+
+For the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE, when creating a resource
+VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA, the driver MUST set all the parameters
+in \field struct virtio_crypto_resource_obj_ipsec_sa with relevant values.
+And when create a resource object VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA,
+the driver MUST set all the parameters except
+\field struct virtio_crypto_ipsec_tunnel_param.
+
+The driver MUST set \field{session_id} in struct virtio_crypto_op_header to a
+valid VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or
+VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA \field{id} .
+The driver MUST set the \field{opcode} field in struct virtio_crypto_op_header
+to one of VIRTIO_CRYPTO_IPSEC_OUTBOUND and VIRTIO_CRYPTO_IPSEC_INBOUND.
diff --git a/device-types/crypto/device-conformance.tex b/device-types/crypto/device-conformance.tex
index 1667120..5d1c59f 100644
--- a/device-types/crypto/device-conformance.tex
+++ b/device-types/crypto/device-conformance.tex
@@ -10,4 +10,5 @@
\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}
+\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / IPsec Service Operation}
\end{itemize}
diff --git a/device-types/crypto/driver-conformance.tex b/device-types/crypto/driver-conformance.tex
index 672d0f6..4083ea4 100644
--- a/device-types/crypto/driver-conformance.tex
+++ b/device-types/crypto/driver-conformance.tex
@@ -11,4 +11,5 @@
\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}
+\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / IPsec Service Operation}
\end{itemize}
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH RFC 4/4] virtio-crypto: Add device and driver requirements for IPsec operation
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
0 siblings, 0 replies; 11+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-12-12 10:15 UTC (permalink / raw)
To: Srujana Challa
Cc: virtio-comment, mst, cohuck, parav, sburla, ndabilpuram, jerinj,
anoobj
On Fri, Nov 15, 2024 at 05:15:23PM +0530, Srujana Challa wrote:
> Add device and driver requirements for IPsec Operation.
>
> Signed-off-by: Srujana Challa <schalla@marvell.com>
> ---
> device-types/crypto/description.tex | 100 +++++++++++++++++++++
> device-types/crypto/device-conformance.tex | 1 +
> device-types/crypto/driver-conformance.tex | 1 +
> 3 files changed, 102 insertions(+)
>
> diff --git a/device-types/crypto/description.tex b/device-types/crypto/description.tex
> index 9c878f7..5ca6602 100644
> --- a/device-types/crypto/description.tex
> +++ b/device-types/crypto/description.tex
> @@ -2238,3 +2238,103 @@ \subsubsection{IPSEC Service Operation}\label{sec:Device Types / Crypto Device /
> \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.
> +
> +\devicenormative{\paragraph}{IPsec Service Operation}{Device Types / Crypto Device / Device Operation / IPsec Service Operation}
> +
> +When the device supports IPsec operations,
> +\begin{itemize}
> +\item the device MUST set VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP, VIRTIO_CRYPTO_IPSEC_SA_CAP
> +capability in the \field{supported_caps} in the command VIRTIO_ADMIN_CMD_CAP_SUPPORT_QUERY.
> +\item the device MUST support the administration commands
> +VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE,
> +VIRTIO_ADMIN_CMD_RESOURCE_OBJ_MODIFY, VIRTIO_ADMIN_CMD_RESOURCE_OBJ_QUERY,
> +VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY for the resource types
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA and VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA.
> +\end{itemize}
> +
> +When any of the VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP or VIRTIO_CRYPTO_IPSEC_SA_CAP
> +capability is disabled, the device MUST set \field{status} to
> +VIRTIO_ADMIN_STATUS_Q_INVALID_OPCODE for the commands
> +VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE,
> +VIRTIO_ADMIN_CMD_RESOURCE_OBJ_MODIFY, VIRTIO_ADMIN_CMD_RESOURCE_OBJ_QUERY,
> +and VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY.
> +
> +The device MUST set \field{status} to VIRTIO_ADMIN_STATUS_EEXIST for the
> +command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE when the resource \field{type}
> +is VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA,
> +if the object is already exists with the supplied \field{id}.
Remove `is` in last sentence.
> +
> +The device MUST set \field{status} to VIRTIO_ADMIN_STATUS_EBUSY for the
> +command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY when the resource \field{type}
> +is VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA,
> +if the object is in use.
> +
> +The device MUST fail the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE with
> +the \field{status} set to VIRTIO_ADMIN_STATUS_EINVAL, for the
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA object if,
> +\begin{itemize}
> +\item \field{id} is greater than or equal to \field{outb_sa_limit}.
> +\item the supplied SA parameters, such as mode, options, cipher and authentication
> + algorithms is not supported in the capabitlity VIRTIO_CRYPTO_IPSEC_SA_CAP.
s/is/are
> +\end{itemize}
> +
> +The device MUST fail the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE with
> +the \field{status} set to VIRTIO_ADMIN_STATUS_EINVAL, for the
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA object if,
> +\begin{itemize}
> +\item \field{id} is greater than or equal to \field{inb_sa_limit}.
> +\item the supplied SA parameters, such as mode, options, cipher and authentication
> + algorithms is not supported in the capabitlity VIRTIO_CRYPTO_IPSEC_SA_CAP.
s/is/are
> +\end{itemize}
> +
> +The device SHOULD maintain a table for subsequent lookups for inbound/outbound data
> +processing with the corresponding SA based on the supplied \field{id}.
> +
> +The device MUST allow recreating the resource objects using the command
> +VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE which was previously destroyed using
> +the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_DESTROY respectively without
> +undergoing a device reset.
> +
> +The device MAY fail the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE with
> +the \field{status} set to VIRTIO_ADMIN_STATUS_EINVAL for the
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA
> +commands if the resource object with the same \field{spi} already exists.
> +
> +On device reset, the device MUST destroy all the resource objects which have been created.
> +
> +The device MUST copy the result of IPsec operation in the \field{dst_data[]}.
> +The device MUST set the \field{status} field in struct virtio_crypto_inhdr to
> +one of the following values of enum VIRTIO_CRYPTO_STATUS:
> +\begin{itemize*}
> +\item VIRTIO_CRYPTO_OK if the operation success.
> +\item VIRTIO_CRYPTO_NOTSUPP if the requested algorithm or operation is unsupported.
> +\item VIRTIO_CRYPTO_BADMSG if the integrity check is failed for IPsec decryption.
> +\item VIRTIO_CRYPTO_INVSESS if the session ID invalid.
> +\item VIRTIO_CRYPTO_ERR if any failure not mentioned above occurs.
> +\end{itemize*}
> +
> +\drivernormative{\paragraph}{IPsec Service Operation}{Device Types / Crypto Device / Device Operation / IPsec Service Operation}
> +
> +The driver MUST query the capabilities using VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY
> +to discover the capability types the device offers.
> +
> +The driver MUST get VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP and VIRTIO_CRYPTO_IPSEC_SA_CAP
> +if listed in VIRTIO_ADMIN_CMD_CAP_ID_LIST_QUERY command result, using
> +VIRTION_ADMIN_CMD_DEVICE_CAP_GET to discover the capabilities the device is
> +able to offer.
> +The driver MUST set VIRTIO_CRYPTO_IPSEC_RESOURCE_CAP and VIRTIO_CRYPTO_IPSEC_SA_CAP
> +using VIRTIO_ADMIN_CMD_DEVICE_CAP_SET to indicate the device which capability
> +the driver uses.
> +
> +For the command VIRTIO_ADMIN_CMD_RESOURCE_OBJ_CREATE, when creating a resource
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA, the driver MUST set all the parameters
> +in \field struct virtio_crypto_resource_obj_ipsec_sa with relevant values.
> +And when create a resource object VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA,
> +the driver MUST set all the parameters except
> +\field struct virtio_crypto_ipsec_tunnel_param.
> +
> +The driver MUST set \field{session_id} in struct virtio_crypto_op_header to a
> +valid VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_OUTBOUND_SA or
> +VIRTIO_CRYPTO_RESOURCE_OBJ_IPSEC_INBOUND_SA \field{id} .
Remove space at the end.
> +The driver MUST set the \field{opcode} field in struct virtio_crypto_op_header
> +to one of VIRTIO_CRYPTO_IPSEC_OUTBOUND and VIRTIO_CRYPTO_IPSEC_INBOUND.
> diff --git a/device-types/crypto/device-conformance.tex b/device-types/crypto/device-conformance.tex
> index 1667120..5d1c59f 100644
> --- a/device-types/crypto/device-conformance.tex
> +++ b/device-types/crypto/device-conformance.tex
> @@ -10,4 +10,5 @@
> \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}
> +\item \ref{devicenormative:Device Types / Crypto Device / Device Operation / IPsec Service Operation}
> \end{itemize}
> diff --git a/device-types/crypto/driver-conformance.tex b/device-types/crypto/driver-conformance.tex
> index 672d0f6..4083ea4 100644
> --- a/device-types/crypto/driver-conformance.tex
> +++ b/device-types/crypto/driver-conformance.tex
> @@ -11,4 +11,5 @@
> \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}
> +\item \ref{drivernormative:Device Types / Crypto Device / Device Operation / IPsec Service Operation}
> \end{itemize}
> --
> 2.25.1
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto
2024-11-15 11:45 [PATCH RFC 0/4] introduce IPsec Service in virtio-crypto Srujana Challa
` (3 preceding siblings ...)
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:19 ` Matias Ezequiel Vara Larsen
4 siblings, 0 replies; 11+ messages in thread
From: Matias Ezequiel Vara Larsen @ 2024-12-12 10:19 UTC (permalink / raw)
To: Srujana Challa
Cc: virtio-comment, mst, cohuck, parav, sburla, ndabilpuram, jerinj,
anoobj
On Fri, Nov 15, 2024 at 05:15:19PM +0530, Srujana Challa wrote:
> This series enhances virtio-crypto by adding support for IPsec
> services. These patches aim to extend the capabilities of virtio-crypto,
> enabling it to handle IPsec operations efficiently. In addition
> to standard crypto processing, the IPsec protocol processing is
> also offloaded to the Crypto device as lookaside operation.
>
> It utilizes new virtio basic facilities, including capability and
> resource objects. Below is a summary of the changes introduced:
>
> Patch1:
> This patch introduces the foundational support for IPsec services within
> the virtio-crypto framework, outlining the necessary capabilities for
> IPsec operations.
>
> Patch2:
> This patch adds resource objects required for programming IPsec Security
> Associations (SAs) for both encryption and decryption processes.
>
> Patch3:
> This patch includes new opcodes specific to IPsec operations,
> facilitating the handling of IPsec data requests within the
> virtio-crypto driver.
>
> Patch4:
> This patch specifies the requirements for both the device and the driver
> to support IPsec operations.
>
> These enhancements are for providing support for IPsec within the
> virtio-crypto device/driver, improving security and performance for
> virtualized environments. We believe these additions will significantly
> benefit users who rely on virtio-crypto for secure data transmission.
>
> Srujana Challa (4):
> virtio-crypto: Add IPsec service operation and Capabilities
> virtio-crypto: Add resource objects for IPsec outbound and inbound SAs
> virtio-crypto: Add new IPsec opcodes to data request
> virtio-crypto: Add device and driver requirements for IPsec operation
>
> device-types/crypto/description.tex | 476 ++++++++++++++++++++-
> device-types/crypto/device-conformance.tex | 1 +
> device-types/crypto/driver-conformance.tex | 1 +
> 3 files changed, 473 insertions(+), 5 deletions(-)
>
> --
Hello,
I went through the patches and I commented some minor changes. I hope to
go deeper in this series in the following iteration to give you better
feedback.
Matias
^ permalink raw reply [flat|nested] 11+ messages in thread