DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: Anoob Joseph <anoob.joseph@caviumnetworks.com>,
	Declan Doherty <declan.doherty@intel.com>,
	Radu Nicolau <radu.nicolau@intel.com>,
	Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	Narayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,
	<dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol
Date: Fri, 15 Dec 2017 15:34:23 +0530	[thread overview]
Message-ID: <408f66b2-b308-cbed-56fb-7d50f7f99724@nxp.com> (raw)
In-Reply-To: <1513327396-22178-3-git-send-email-anoob.joseph@caviumnetworks.com>

On 12/15/2017 2:13 PM, Anoob Joseph wrote:
> Adding support for inline protocol processing
> 
> In ingress side, application will receive regular IP packets, without
> any IPsec related info. Application will do a selector check (SP-SA
> check) by making use of the metadata from the packet. The
> device-specific metadata in mbuf would aid in determing the security
> session which processed the packet.
> 
> In egress side, the plain packet would be submitted to the driver. The
> packet will have optional metadata, which could be used to identify the
> security session associated with the packet.
> 
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> v5:
> * Fixed checkpatch reported warnings
> 
> v4:
> * Directly using rte_mbuf.udata64 as the metadata from the packet
> * Removed usage of rte_security_get_pkt_metadata API
> 
> v3:
> * Using (void *)userdata instead of 64 bit metadata in conf
> * Changes parallel to the change in API
> 
> v2:
> * Using get_pkt_metadata API instead of get_session & get_cookie APIs
> 
>   examples/ipsec-secgw/esp.c         |   6 +-
>   examples/ipsec-secgw/ipsec-secgw.c |  42 ++++++++++++-
>   examples/ipsec-secgw/ipsec.c       | 121 +++++++++++++++++++++++++++++++------
>   3 files changed, 147 insertions(+), 22 deletions(-)
> 
> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
> index c3efe52..561f873 100644
> --- a/examples/ipsec-secgw/esp.c
> +++ b/examples/ipsec-secgw/esp.c
> @@ -178,7 +178,8 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa *sa,
>   	RTE_ASSERT(sa != NULL);
>   	RTE_ASSERT(cop != NULL);
>   
> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>   		if (m->ol_flags & PKT_RX_SEC_OFFLOAD) {
>   			if (m->ol_flags & PKT_RX_SEC_OFFLOAD_FAILED)
>   				cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
> @@ -474,7 +475,8 @@ esp_outbound_post(struct rte_mbuf *m,
>   	RTE_ASSERT(m != NULL);
>   	RTE_ASSERT(sa != NULL);
>   
> -	if (sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) {
> +	if ((sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) ||
> +			(sa->type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO)) {
>   		m->ol_flags |= PKT_TX_SEC_OFFLOAD;
>   	} else {
>   		RTE_ASSERT(cop != NULL);
> diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
> index c98454a..8254056 100644
> --- a/examples/ipsec-secgw/ipsec-secgw.c
> +++ b/examples/ipsec-secgw/ipsec-secgw.c
> @@ -265,6 +265,40 @@ prepare_one_packet(struct rte_mbuf *pkt, struct ipsec_traffic *t)
>   		RTE_LOG(ERR, IPSEC, "Unsupported packet type\n");
>   		rte_pktmbuf_free(pkt);
>   	}
> +
> +	/* Check if the packet has been processed inline. For inline protocol
> +	 * processed packets, the metadata in the mbuf can be used to identify
> +	 * the security processing done on the packet. The metadata will be
> +	 * used to retrieve the application registered userdata associated
> +	 * with the security session.
> +	 */
> +
> +	if (pkt->ol_flags & PKT_RX_SEC_OFFLOAD) {
> +		struct ipsec_sa *sa;
> +		struct ipsec_mbuf_metadata *priv;
> +		struct rte_security_ctx *ctx = (struct rte_security_ctx *)
> +						rte_eth_dev_get_sec_ctx(
> +						pkt->port);
> +
> +		/* Retrieve the userdata registered. Here, the userdata
> +		 * registered is the SA pointer.
> +		 */
> +
> +		sa = (struct ipsec_sa *)
> +				rte_security_get_userdata(ctx, pkt->udata64);
> +
> +		if (sa == NULL) {
> +			/* userdata could not be retrieved */
Is it mandatory to get userdata for all devices which support 
PKT_RX_SEC_OFFLOAD? I believe not. So you cannot return from here if the 
device does not need userdata.

> +			return;
> +		}
> +
> +		/* Save SA as priv member in mbuf. This will be used in the
> +		 * IPsec selector(SP-SA) check.
> +		 */
> +
> +		priv = get_priv(pkt);
> +		priv->sa = sa;
> +	}
>   }
>   
>   static inline void
> @@ -401,11 +435,17 @@ inbound_sp_sa(struct sp_ctx *sp, struct sa_ctx *sa, struct traffic_type *ip,
>   			ip->pkts[j++] = m;
>   			continue;
>   		}
> -		if (res & DISCARD || i < lim) {
> +		if (res & DISCARD) {
>   			rte_pktmbuf_free(m);
>   			continue;
>   		}
> +
>   		/* Only check SPI match for processed IPSec packets */
> +		if (i < lim && ((m->ol_flags & PKT_RX_SEC_OFFLOAD) == 0)) {
> +			rte_pktmbuf_free(m);
> +			continue;
> +		}
> +
>   		sa_idx = ip->res[i] & PROTECT_MASK;
>   		if (sa_idx == 0 || !inbound_sa_check(sa, m, sa_idx)) {
>   			rte_pktmbuf_free(m);
> diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
> index 70ed227..bd68ec6 100644
> --- a/examples/ipsec-secgw/ipsec.c
> +++ b/examples/ipsec-secgw/ipsec.c
> @@ -46,6 +46,27 @@
>   #include "ipsec.h"
>   #include "esp.h"
>   
> +static inline void
> +set_ipsec_conf(struct ipsec_sa *sa, struct rte_security_ipsec_xform *ipsec)
> +{
> +	if (ipsec->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> +		struct rte_security_ipsec_tunnel_param *tunnel =
> +				&ipsec->tunnel;
> +		if (sa->flags == IP4_TUNNEL) {
> +			tunnel->type =
> +				RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> +			tunnel->ipv4.ttl = IPDEFTTL;
> +
> +			memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> +				(uint8_t *)&sa->src.ip.ip4, 4);
> +
> +			memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> +				(uint8_t *)&sa->dst.ip.ip4, 4);
> +		}
> +		/* TODO support for Transport and IPV6 tunnel */
> +	}
> +}
> +
>   static inline int
>   create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   {
> @@ -95,7 +116,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL :
>   					RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT,
>   			} },
> -			.crypto_xform = sa->xforms
> +			.crypto_xform = sa->xforms,
> +			.userdata = NULL,
>   
>   		};
>   
> @@ -104,23 +126,8 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   							rte_cryptodev_get_sec_ctx(
>   							ipsec_ctx->tbl[cdev_id_qp].id);
>   
> -			if (sess_conf.ipsec.mode ==
> -					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) {
> -				struct rte_security_ipsec_tunnel_param *tunnel =
> -						&sess_conf.ipsec.tunnel;
> -				if (sa->flags == IP4_TUNNEL) {
> -					tunnel->type =
> -						RTE_SECURITY_IPSEC_TUNNEL_IPV4;
> -					tunnel->ipv4.ttl = IPDEFTTL;
> -
> -					memcpy((uint8_t *)&tunnel->ipv4.src_ip,
> -						(uint8_t *)&sa->src.ip.ip4, 4);
> -
> -					memcpy((uint8_t *)&tunnel->ipv4.dst_ip,
> -						(uint8_t *)&sa->dst.ip.ip4, 4);
> -				}
> -				/* TODO support for Transport and IPV6 tunnel */
> -			}
> +			/* Set IPsec parameters in conf */
> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
>   
>   			sa->sec_session = rte_security_session_create(ctx,
>   					&sess_conf, ipsec_ctx->session_pool);
> @@ -206,6 +213,70 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
>   					err.message);
>   				return -1;
>   			}
> +		} else if (sa->type ==
> +				RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
> +			struct rte_security_ctx *ctx =
> +					(struct rte_security_ctx *)
> +					rte_eth_dev_get_sec_ctx(sa->portid);
> +			const struct rte_security_capability *sec_cap;
> +
> +			if (ctx == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"Ethernet device doesn't have security features registered\n");
> +				return -1;
> +			}
> +
> +			/* Set IPsec parameters in conf */
> +			set_ipsec_conf(sa, &(sess_conf.ipsec));
> +
> +			/* Save SA as userdata for the security session. When
> +			 * the packet is received, this userdata will be
> +			 * retrieved using the metadata from the packet.
> +			 *
> +			 * This is required only for inbound SAs.
> +			 */
> +
> +			if (sa->direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS)
> +				sess_conf.userdata = (void *) sa;
> +
> +			sa->sec_session = rte_security_session_create(ctx,
> +					&sess_conf, ipsec_ctx->session_pool);
> +			if (sa->sec_session == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"SEC Session init failed: err: %d\n", ret);
> +				return -1;
> +			}
> +
> +			sec_cap = rte_security_capabilities_get(ctx);
> +
> +			if (sec_cap == NULL) {
> +				RTE_LOG(ERR, IPSEC,
> +				"No capabilities registered\n");
> +				return -1;
> +			}
> +
> +			/* iterate until ESP tunnel*/
> +			while (sec_cap->action !=
> +					RTE_SECURITY_ACTION_TYPE_NONE) {
> +
> +				if (sec_cap->action == sa->type &&
> +				    sec_cap->protocol ==
> +					RTE_SECURITY_PROTOCOL_IPSEC &&
> +				    sec_cap->ipsec.mode ==
> +					RTE_SECURITY_IPSEC_SA_MODE_TUNNEL &&
> +				    sec_cap->ipsec.direction == sa->direction)
> +					break;
> +				sec_cap++;
> +			}
> +
> +			if (sec_cap->action == RTE_SECURITY_ACTION_TYPE_NONE) {
> +				RTE_LOG(ERR, IPSEC,
> +				"No suitable security capability found\n");
> +				return -1;
> +			}
> +
> +			sa->ol_flags = sec_cap->ol_flags;
> +			sa->security_ctx = ctx;
>   		}
>   	} else {
>   		sa->crypto_session = rte_cryptodev_sym_session_create(
> @@ -323,7 +394,19 @@ ipsec_enqueue(ipsec_xform_fn xform_func, struct ipsec_ctx *ipsec_ctx,
>   			}
>   			break;
>   		case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
> -			break;
> +			if ((unlikely(sa->sec_session == NULL)) &&
> +					create_session(ipsec_ctx, sa)) {
> +				rte_pktmbuf_free(pkts[i]);
> +				continue;
> +			}
> +
> +			cqp = &ipsec_ctx->tbl[sa->cdev_id_qp];
> +			cqp->ol_pkts[cqp->ol_pkts_cnt++] = pkts[i];
> +			if (sa->ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
> +				rte_security_set_pkt_metadata(
> +						sa->security_ctx,
> +						sa->sec_session, pkts[i], NULL);
> +			continue;
>   		case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
>   			priv->cop.type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
>   			priv->cop.status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
> 

  parent reply	other threads:[~2017-12-15 10:04 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-20 10:31 [dpdk-dev] [PATCH 0/2] add inline protocol support Anoob Joseph
2017-11-20 10:31 ` [dpdk-dev] [PATCH 1/2] lib/security: add support for saving app cookie Anoob Joseph
2017-11-20 12:12   ` Radu Nicolau
2017-11-20 15:32     ` Anoob
2017-11-20 17:49       ` Radu Nicolau
2017-11-20 19:09         ` Anoob Joseph
2017-11-21 10:15           ` Radu Nicolau
2017-11-20 10:31 ` [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph
2017-11-22  6:55 ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Anoob Joseph
2017-11-22  6:55   ` [dpdk-dev] [PATCH v2 1/2] lib/security: add support for get metadata Anoob Joseph
2017-11-22 11:29     ` Radu Nicolau
2017-11-22 11:52       ` Anoob
2017-11-22 12:12         ` Radu Nicolau
2017-11-22 13:27     ` Neil Horman
2017-11-22 14:13       ` Anoob
2017-11-27 13:55         ` Neil Horman
2017-11-22  6:55   ` [dpdk-dev] [PATCH v2 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph
2017-11-22 12:21   ` [dpdk-dev] [PATCH v2 0/2] add inline protocol support Nelio Laranjeiro
2017-11-22 12:55     ` Anoob
2017-11-22 13:05       ` Nelio Laranjeiro
2017-11-22 13:38         ` Anoob
2017-11-22 13:53           ` Anoob
2017-11-22 15:13         ` Anoob
2017-11-22 15:25           ` Nelio Laranjeiro
2017-11-23 11:19   ` [dpdk-dev] [PATCH v3 " Anoob Joseph
2017-11-23 11:19     ` [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata Anoob Joseph
2017-11-24  8:50       ` Akhil Goyal
2017-11-24  9:39         ` Radu Nicolau
2017-11-24 10:55           ` Akhil Goyal
2017-11-24 11:17             ` Radu Nicolau
2017-11-24 11:34               ` Akhil Goyal
2017-11-24 11:59                 ` Radu Nicolau
2017-11-24 12:03                   ` Akhil Goyal
2017-12-06  7:30                     ` Anoob
2017-12-06  9:43                       ` Radu Nicolau
2017-12-11  7:21                         ` Anoob
2017-12-12  8:55                           ` Akhil Goyal
2017-12-12 13:50                             ` Anoob Joseph
2017-12-13 14:38                               ` Akhil Goyal
2017-11-24 12:22                 ` Anoob
2017-11-29  5:43                   ` Anoob
2017-12-04  9:28                   ` Akhil Goyal
2017-12-04 10:16                     ` Anoob
2017-11-23 11:19     ` [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph
2017-12-11 11:02       ` Radu Nicolau
2017-12-15  8:30     ` [dpdk-dev] [PATCH v4 0/2] add inline protocol support Anoob Joseph
2017-12-15  8:30       ` [dpdk-dev] [PATCH v4 1/2] lib/security: add support for get userdata Anoob Joseph
2017-12-15  8:30       ` [dpdk-dev] [PATCH v4 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph
2017-12-15  8:43       ` [dpdk-dev] [PATCH v5 0/2] add inline protocol support Anoob Joseph
2017-12-15  8:43         ` [dpdk-dev] [PATCH v5 1/2] lib/security: add support for get userdata Anoob Joseph
2017-12-15 10:01           ` Akhil Goyal
2017-12-15 10:53             ` Anoob Joseph
2017-12-15 10:58               ` Akhil Goyal
2017-12-15  8:43         ` [dpdk-dev] [PATCH v5 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph
2017-12-15  9:39           ` Nelio Laranjeiro
2017-12-15 11:03             ` Anoob Joseph
2017-12-15 13:35               ` Nelio Laranjeiro
2017-12-15 10:04           ` Akhil Goyal [this message]
2017-12-15 11:16             ` Anoob Joseph
2017-12-18  7:15         ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support Anoob Joseph
2017-12-18  7:15           ` [dpdk-dev] [PATCH v6 1/2] lib/security: add support for get userdata Anoob Joseph
2017-12-18  7:34             ` Akhil Goyal
2017-12-18  7:15           ` [dpdk-dev] [PATCH v6 2/2] examples/ipsec-secgw: add support for inline protocol Anoob Joseph
2018-01-08 16:10             ` De Lara Guarch, Pablo
2018-01-09  9:12             ` Akhil Goyal
2018-01-16 11:00             ` Nicolau, Radu
2018-01-09 16:05           ` [dpdk-dev] [PATCH v6 0/2] add inline protocol support De Lara Guarch, Pablo

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=408f66b2-b308-cbed-56fb-7d50f7f99724@nxp.com \
    --to=akhil.goyal@nxp.com \
    --cc=anoob.joseph@caviumnetworks.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=narayanaprasad.athreya@caviumnetworks.com \
    --cc=radu.nicolau@intel.com \
    --cc=sergio.gonzalez.monroy@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).