IB/core: Add ESP Crypto Flow Steering support

From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/[email protected]>

The purpose of this RFC is to suggest an API for specifying ESP crypto offload via flow steering. This API will allow users to control the crypto offload functionality offered by new NICs, such as Mellanox Innova IPsec.

Applications can request ESP encryption offload for transmission of well-formed plaintext ESP packets, or decryption offload for well-fromed ciphertext ESP packets. Packets are encrypted/decrypted according to the direction of the flow.

In order to create an ESP crypto offload specification, the user has to add it to a flow with the Security Association selectors.

borisp (2):
Introduce egress IB flow steering flag
IB/core: ESP AES-GCM crypto offload action

 include/rdma/ib_verbs.h | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/[email protected]>

This commit introduces egress flow steering. Egress flow steering is useful for specifying actions that might be applied by hardware to outgoing flows on a specific QP.

---
 include/rdma/ib_verbs.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index 99e4423..6c1c867 100644
@@ -1679,7 +1679,8 @@ enum ib_flow_domain {
 
 enum ib_flow_flags {
 	IB_FLOW_ATTR_FLAGS_DONT_TRAP = 1UL << 1, /* Continue match, no steal */
-	IB_FLOW_ATTR_FLAGS_RESERVED  = 1UL << 2  /* Must be last */
+	IB_FLOW_ATTR_FLAGS_EGRESS = 1UL << 2, /* Egress steering rule */
+	IB_FLOW_ATTR_FLAGS_RESERVED  = 1UL << 3  /* Must be last */
 };
 
 struct ib_flow_eth_filter {

1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How will user know which flow actions are applicable for egress traffic, for both ingress/egress and for ingress only?

I think separate structure for ingress vs. egress are better approach, than blind global flag.

Please configure your git, "Signed-off-by" line is a legal document and supposed to have proper author name.

Thanks

The implementation could return an error when a device doesn't support a certain action. For example, we may not support crypto offload for encapsulation of IPsec packets, and we will return an error if such a flow specification is provided.

Did you have any specific action that is not supported in some direction? AFAIK, we support all action for egress as well as ingress.

I thought of using a direction flag in the action itself, but decided against it , because all flow specification refer to a certain direction and not the action alone. Moreover, there are other actions that will be based on this flag, like encapsulation actions.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

From: borisp <borisp-VPRAkNaXOzVWk0Htik3J/[email protected]>

This patch introduces the flow steering specification for IPsec AES-GCM crypto offload to HW. If a user creates a flow with this specification, then all packets that hit this flow will have their payload encrypted and authenticated according to the key and the salt in this specification as defined in RFC4303.

---
 include/rdma/ib_verbs.h | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

index 6c1c867..e4e33e4 100644
@@ -1658,10 +1658,12 @@ enum ib_flow_spec_type {
 	/* L4 headers*/
 	IB_FLOW_SPEC_TCP		= 0x40,
 	IB_FLOW_SPEC_UDP		= 0x41,
+	IB_FLOW_SPEC_ESP		= 0x42,
 	IB_FLOW_SPEC_VXLAN_TUNNEL	= 0x50,
 	IB_FLOW_SPEC_INNER		= 0x100,
 	/* Actions */
 	IB_FLOW_SPEC_ACTION_TAG         = 0x1000,
+	IB_FLOW_SPEC_ACTION_ESP_AES_GCM         = 0x1001,
 };
 #define IB_FLOW_SPEC_LAYER_MASK	0xF0
 #define IB_FLOW_SPEC_SUPPORT_LAYERS 8

@@ -1770,6 +1772,20 @@ struct ib_flow_spec_tcp_udp {
 	struct ib_flow_tcp_udp_filter mask;
 };
 
+struct ib_flow_esp_filter {
+		__be32	spi;
+		__be32  seq;
+		/* Must be last */
+		u8	real_sz[0];
+};
+
+struct ib_flow_spec_esp {
+	u32                           type;
+	u16			      size;
+	struct ib_flow_esp_filter     val;
+	struct ib_flow_esp_filter     mask;
+};
+
 struct ib_flow_tunnel_filter {
 	__be32	tunnel_id;
 	u8	real_sz[0];

@@ -1791,6 +1807,16 @@ struct ib_flow_spec_action_tag {
 	u32                           tag_id;
 };
 
+struct ib_flow_spec_action_esp_aes_gcm {
+	enum ib_flow_spec_type	      type;
+	u16			      size;
+	__u8                          key[32];
+	__u8                          key_length; /* 16, 24 or 32 bytes */
+	__u8                          salt[4]; /* salt according to RFC4106 */
+	__u8                          seqiv_salt[8];
+	__u8			      seq_hi[4];
+};
+
 union ib_flow_spec {
 	struct {
 		u32			type;

@@ -1802,7 +1828,9 @@ struct ib_flow_spec_action_tag {
 	struct ib_flow_spec_tcp_udp	tcp_udp;
 	struct ib_flow_spec_ipv6        ipv6;
 	struct ib_flow_spec_tunnel      tunnel;
+	struct ib_flow_spec_esp		esp;
 	struct ib_flow_spec_action_tag  flow_tag;
+	struct ib_flow_spec_action_esp_aes_gcm  esp_aes_gcm;
 };
 
 struct ib_flow_attr {

1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hey Boris,

Do you have any applications that utilize this and other flow steering APIs? It would be nice to see example usage.

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Our DPDK PMD already utilizes flow steering and it will use this API.

Also, we have support for this offload in XFRM, but it doesn't use flow steering at the moment. In the future, XFRM NDO will use flow steering through our driver. Patches for the kernel XFRM code can be found here:
https://patchwork.ozlabs.org/patch/752707/
Our driver support for this framework in XFRM can be found here:
https://github.com/Mellanox/ipsec-offload
XFRM is programmed with iproute2. You can find code for it here:
https://github.com/Mellanox/iproute2

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Your patches didn't change any uapi headers - how does this get exported to user space?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Right. Sorry about that. The intent is to export both ib_flow_spec_action_esp_aes_gcm and ib_flow_spec_esp to user space.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html