[dpdk-dev,1/2] lib/security: add support for saving app cookie
Checks
Commit Message
In case of inline protocol processed ingress traffic, the packet may not
have enough information to determine the security parameters with which
the packet was processed. In such cases, the application could register
a cookie, which will be saved in the the security session.
As the ingress packets are received in the application, it will have
some metadata set in the mbuf. Application can pass this metadata to
"rte_security_session_get" API to retrieve the security session. Once
the security session is determined, another driver call with the
security session will give the application the cookie it had registered.
The cookie will be registered while creating the security session.
Without the cookie, the selector check (SP-SA check) for the incoming
IPsec traffic won't be possible in the application.
Application can choose what it should register as the cookie. It can
register SPI or a pointer to SA.
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
---
lib/librte_security/rte_security.c | 26 +++++++++++++++++++++++
lib/librte_security/rte_security.h | 30 +++++++++++++++++++++++++++
lib/librte_security/rte_security_driver.h | 34 +++++++++++++++++++++++++++++++
3 files changed, 90 insertions(+)
Comments
Hi,
Why not have something similar to rte_security_set_pkt_metadata, for
example:
void *
rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
struct rte_mbuf *mb);
and keep internally in the PMD all the required references. The returned
value will be device-specific, so it's flexible enough to include
anything required (just as void *params is in the set_pkt_metadata).
I think it will make a cleaner and more consistent implementation.
Regards,
Radu
On 11/20/2017 10:31 AM, Anoob Joseph wrote:
> In case of inline protocol processed ingress traffic, the packet may not
> have enough information to determine the security parameters with which
> the packet was processed. In such cases, the application could register
> a cookie, which will be saved in the the security session.
>
> As the ingress packets are received in the application, it will have
> some metadata set in the mbuf. Application can pass this metadata to
> "rte_security_session_get" API to retrieve the security session. Once
> the security session is determined, another driver call with the
> security session will give the application the cookie it had registered.
>
> The cookie will be registered while creating the security session.
> Without the cookie, the selector check (SP-SA check) for the incoming
> IPsec traffic won't be possible in the application.
>
> Application can choose what it should register as the cookie. It can
> register SPI or a pointer to SA.
>
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> ---
> lib/librte_security/rte_security.c | 26 +++++++++++++++++++++++
> lib/librte_security/rte_security.h | 30 +++++++++++++++++++++++++++
> lib/librte_security/rte_security_driver.h | 34 +++++++++++++++++++++++++++++++
> 3 files changed, 90 insertions(+)
>
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> index 1227fca..1c706fe 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -98,6 +98,32 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
> return ret;
> }
>
> +struct rte_security_session *
> +rte_security_session_get(struct rte_security_ctx *instance,
> + uint64_t mdata)
> +{
> + struct rte_security_session *sess = NULL;
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->session_get, NULL);
> + if (instance->ops->session_get(instance->device, mdata, &sess))
> + return NULL;
> +
> + return sess;
> +}
> +
> +uint64_t
> +rte_security_cookie_get(struct rte_security_ctx *instance,
> + struct rte_security_session *sess)
> +{
> + uint64_t cookie = 0;
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->cookie_get, 0);
> + if (instance->ops->cookie_get(instance->device, sess, &cookie))
> + return 0;
> +
> + return cookie;
> +}
> +
> int
> rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
> struct rte_security_session *sess,
> diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
> index 7e687d2..95f81ee 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -273,6 +273,8 @@ struct rte_security_session_conf {
> /**< Configuration parameters for security session */
> struct rte_crypto_sym_xform *crypto_xform;
> /**< Security Session Crypto Transformations */
> + uint64_t cookie;
> + /**< Cookie registered by application */
> };
>
> struct rte_security_session {
> @@ -327,6 +329,34 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
> struct rte_security_session *sess);
>
> /**
> + * Get the security session from the metadata set in mbuf.
> + *
> + * @param instance security instance
> + * @param mdata metadata set in mbuf during rx offload
> + * @return
> + * - On success, pointer to session
> + * - On failure, NULL
> + */
> +struct rte_security_session *
> +rte_security_session_get(struct rte_security_ctx *instance,
> + uint64_t mdata);
> +
> +/**
> + * Get the cookie set by application while creating the session. This could be
> + * used to identify the SA associated with the session.
> + *
> + * @param instance security instance
> + * @param sess security session
> + *
> + * @return
> + * - On success, cookie
> + * - On failure, 0
> + */
> +uint64_t
> +rte_security_cookie_get(struct rte_security_ctx *instance,
> + struct rte_security_session *sess);
> +
> +/**
> * Updates the buffer with device-specific defined metadata
> *
> * @param instance security instance
> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_security/rte_security_driver.h
> index 997fbe7..f503be6a 100644
> --- a/lib/librte_security/rte_security_driver.h
> +++ b/lib/librte_security/rte_security_driver.h
> @@ -107,6 +107,36 @@ typedef int (*security_session_stats_get_t)(void *device,
> struct rte_security_stats *stats);
>
> /**
> + * Get the security session from the metadata set in mbuf.
> + *
> + * @param device Crypto/eth device pointer
> + * @param mdata Metadata set in mbuf during rx offload
> + * @param sess Pointer to return the security session retrieved
> + *
> + * @return
> + * - Returns 0 if the security session was successfully retrieved.
> + * - Returns -EINVAL if input parameters are invalid.
> + */
> +typedef int (*security_session_get_t)(void *device,
> + uint64_t mdata,
> + struct rte_security_session **sess);
> +
> +/**
> + * Get the cookie associated with the security session.
> + *
> + * @param device Crypto/eth device pointer
> + * @param sess Security session
> + * @param cookie Cookie associated with the security session
> + *
> + * @return
> + * - Returns 0 if the cookie was successfully retrieved.
> + * - Returns -EINVAL if input parameters are invalid.
> + */
> +typedef int (*security_cookie_get_t)(void *device,
> + struct rte_security_session *sess,
> + uint64_t *cookie);
> +
> +/**
> * Update the mbuf with provided metadata.
> *
> * @param sess Security session structure
> @@ -143,6 +173,10 @@ struct rte_security_ops {
> /**< Get security session statistics. */
> security_session_destroy_t session_destroy;
> /**< Clear a security sessions private data. */
> + security_session_get_t session_get;
> + /**< Get the security session associated with the metadata */
> + security_cookie_get_t cookie_get;
> + /**< Get the cookie associated with the security session */
> security_set_pkt_metadata_t set_pkt_metadata;
> /**< Update mbuf metadata. */
> security_capabilities_get_t capabilities_get;
Hi,
Having something like "get_pkt_metadata" should be fine for inline
protocol usage. But we will still need a "get cookie" call to get the
cookie, as the application would need something it can interpret.
And, even though it seems both are symmetric operations(get & set pkt
metadata), there are some minor differences in what they would do. Set
metadata would be setting metadata(udata64 member) in mbuf, while get
metadata is not exactly returning metadata. We use the actual metadata
to get something else(security session in the proposed patch). That was
the primary motive for adding "session_get" API.
Thanks,
Anoob
On 11/20/2017 05:42 PM, Radu Nicolau wrote:
> Hi,
>
>
> Why not have something similar to rte_security_set_pkt_metadata, for
> example:
>
> void *
> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
> struct rte_mbuf *mb);
>
> and keep internally in the PMD all the required references. The
> returned value will be device-specific, so it's flexible enough to
> include anything required (just as void *params is in the
> set_pkt_metadata).
>
> I think it will make a cleaner and more consistent implementation.
>
>
> Regards,
>
> Radu
>
>
>
> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>> In case of inline protocol processed ingress traffic, the packet may not
>> have enough information to determine the security parameters with which
>> the packet was processed. In such cases, the application could register
>> a cookie, which will be saved in the the security session.
>>
>> As the ingress packets are received in the application, it will have
>> some metadata set in the mbuf. Application can pass this metadata to
>> "rte_security_session_get" API to retrieve the security session. Once
>> the security session is determined, another driver call with the
>> security session will give the application the cookie it had registered.
>>
>> The cookie will be registered while creating the security session.
>> Without the cookie, the selector check (SP-SA check) for the incoming
>> IPsec traffic won't be possible in the application.
>>
>> Application can choose what it should register as the cookie. It can
>> register SPI or a pointer to SA.
>>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> ---
>> lib/librte_security/rte_security.c | 26 +++++++++++++++++++++++
>> lib/librte_security/rte_security.h | 30
>> +++++++++++++++++++++++++++
>> lib/librte_security/rte_security_driver.h | 34
>> +++++++++++++++++++++++++++++++
>> 3 files changed, 90 insertions(+)
>>
>> diff --git a/lib/librte_security/rte_security.c
>> b/lib/librte_security/rte_security.c
>> index 1227fca..1c706fe 100644
>> --- a/lib/librte_security/rte_security.c
>> +++ b/lib/librte_security/rte_security.c
>> @@ -98,6 +98,32 @@ rte_security_session_destroy(struct
>> rte_security_ctx *instance,
>> return ret;
>> }
>> +struct rte_security_session *
>> +rte_security_session_get(struct rte_security_ctx *instance,
>> + uint64_t mdata)
>> +{
>> + struct rte_security_session *sess = NULL;
>> +
>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->session_get, NULL);
>> + if (instance->ops->session_get(instance->device, mdata, &sess))
>> + return NULL;
>> +
>> + return sess;
>> +}
>> +
>> +uint64_t
>> +rte_security_cookie_get(struct rte_security_ctx *instance,
>> + struct rte_security_session *sess)
>> +{
>> + uint64_t cookie = 0;
>> +
>> + RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->cookie_get, 0);
>> + if (instance->ops->cookie_get(instance->device, sess, &cookie))
>> + return 0;
>> +
>> + return cookie;
>> +}
>> +
>> int
>> rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
>> struct rte_security_session *sess,
>> diff --git a/lib/librte_security/rte_security.h
>> b/lib/librte_security/rte_security.h
>> index 7e687d2..95f81ee 100644
>> --- a/lib/librte_security/rte_security.h
>> +++ b/lib/librte_security/rte_security.h
>> @@ -273,6 +273,8 @@ struct rte_security_session_conf {
>> /**< Configuration parameters for security session */
>> struct rte_crypto_sym_xform *crypto_xform;
>> /**< Security Session Crypto Transformations */
>> + uint64_t cookie;
>> + /**< Cookie registered by application */
>> };
>> struct rte_security_session {
>> @@ -327,6 +329,34 @@ rte_security_session_destroy(struct
>> rte_security_ctx *instance,
>> struct rte_security_session *sess);
>> /**
>> + * Get the security session from the metadata set in mbuf.
>> + *
>> + * @param instance security instance
>> + * @param mdata metadata set in mbuf during rx offload
>> + * @return
>> + * - On success, pointer to session
>> + * - On failure, NULL
>> + */
>> +struct rte_security_session *
>> +rte_security_session_get(struct rte_security_ctx *instance,
>> + uint64_t mdata);
>> +
>> +/**
>> + * Get the cookie set by application while creating the session.
>> This could be
>> + * used to identify the SA associated with the session.
>> + *
>> + * @param instance security instance
>> + * @param sess security session
>> + *
>> + * @return
>> + * - On success, cookie
>> + * - On failure, 0
>> + */
>> +uint64_t
>> +rte_security_cookie_get(struct rte_security_ctx *instance,
>> + struct rte_security_session *sess);
>> +
>> +/**
>> * Updates the buffer with device-specific defined metadata
>> *
>> * @param instance security instance
>> diff --git a/lib/librte_security/rte_security_driver.h
>> b/lib/librte_security/rte_security_driver.h
>> index 997fbe7..f503be6a 100644
>> --- a/lib/librte_security/rte_security_driver.h
>> +++ b/lib/librte_security/rte_security_driver.h
>> @@ -107,6 +107,36 @@ typedef int (*security_session_stats_get_t)(void
>> *device,
>> struct rte_security_stats *stats);
>> /**
>> + * Get the security session from the metadata set in mbuf.
>> + *
>> + * @param device Crypto/eth device pointer
>> + * @param mdata Metadata set in mbuf during rx offload
>> + * @param sess Pointer to return the security session
>> retrieved
>> + *
>> + * @return
>> + * - Returns 0 if the security session was successfully retrieved.
>> + * - Returns -EINVAL if input parameters are invalid.
>> + */
>> +typedef int (*security_session_get_t)(void *device,
>> + uint64_t mdata,
>> + struct rte_security_session **sess);
>> +
>> +/**
>> + * Get the cookie associated with the security session.
>> + *
>> + * @param device Crypto/eth device pointer
>> + * @param sess Security session
>> + * @param cookie Cookie associated with the security session
>> + *
>> + * @return
>> + * - Returns 0 if the cookie was successfully retrieved.
>> + * - Returns -EINVAL if input parameters are invalid.
>> + */
>> +typedef int (*security_cookie_get_t)(void *device,
>> + struct rte_security_session *sess,
>> + uint64_t *cookie);
>> +
>> +/**
>> * Update the mbuf with provided metadata.
>> *
>> * @param sess Security session structure
>> @@ -143,6 +173,10 @@ struct rte_security_ops {
>> /**< Get security session statistics. */
>> security_session_destroy_t session_destroy;
>> /**< Clear a security sessions private data. */
>> + security_session_get_t session_get;
>> + /**< Get the security session associated with the metadata */
>> + security_cookie_get_t cookie_get;
>> + /**< Get the cookie associated with the security session */
>> security_set_pkt_metadata_t set_pkt_metadata;
>> /**< Update mbuf metadata. */
>> security_capabilities_get_t capabilities_get;
>
Hi
On 11/20/2017 3:32 PM, Anoob wrote:
> Hi,
>
> Having something like "get_pkt_metadata" should be fine for inline
> protocol usage. But we will still need a "get cookie" call to get the
> cookie, as the application would need something it can interpret.
Why can't you have a get_pkt_metadata that returns the "cookie" - which
I would call it userdata or similar? What I'm trying to say is that we
should try to keep it as generic as possible. For example, I wouldn't
assume that the cookie is stored in pkt->udata64 in the application.
> And, even though it seems both are symmetric operations(get & set pkt
> metadata), there are some minor differences in what they would do. Set
> metadata would be setting metadata(udata64 member) in mbuf, while get
> metadata is not exactly returning metadata. We use the actual metadata
> to get something else(security session in the proposed patch). That
> was the primary motive for adding "session_get" API.
What they do exactly is left to the PMD implementation. From the user's
perspective, it does not matter.
There is no requirement that set pkt metadata will set the udata64 member.
>
> Thanks,
> Anoob
>
> On 11/20/2017 05:42 PM, Radu Nicolau wrote:
>> Hi,
>>
>>
>> Why not have something similar to rte_security_set_pkt_metadata, for
>> example:
>>
>> void *
>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>> struct rte_mbuf *mb);
>>
>> and keep internally in the PMD all the required references. The
>> returned value will be device-specific, so it's flexible enough to
>> include anything required (just as void *params is in the
>> set_pkt_metadata).
>>
>> I think it will make a cleaner and more consistent implementation.
>>
>>
>> Regards,
>>
>> Radu
>>
>>
>>
>> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>>> In case of inline protocol processed ingress traffic, the packet may
>>> not
>>> have enough information to determine the security parameters with which
>>> the packet was processed. In such cases, the application could register
>>> a cookie, which will be saved in the the security session.
>>>
>>> As the ingress packets are received in the application, it will have
>>> some metadata set in the mbuf. Application can pass this metadata to
>>> "rte_security_session_get" API to retrieve the security session. Once
>>> the security session is determined, another driver call with the
>>> security session will give the application the cookie it had
>>> registered.
>>>
>>> The cookie will be registered while creating the security session.
>>> Without the cookie, the selector check (SP-SA check) for the incoming
>>> IPsec traffic won't be possible in the application.
>>>
>>> Application can choose what it should register as the cookie. It can
>>> register SPI or a pointer to SA.
>>>
>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>> ---
>>> lib/librte_security/rte_security.c | 26
>>> +++++++++++++++++++++++
>>> lib/librte_security/rte_security.h | 30
>>> +++++++++++++++++++++++++++
>>> lib/librte_security/rte_security_driver.h | 34
>>> +++++++++++++++++++++++++++++++
>>> 3 files changed, 90 insertions(+)
>>> <snip>
>
Hi
See inline.
On 20-11-2017 23:19, Radu Nicolau wrote:
> Hi
>
>
> On 11/20/2017 3:32 PM, Anoob wrote:
>> Hi,
>>
>> Having something like "get_pkt_metadata" should be fine for inline
>> protocol usage. But we will still need a "get cookie" call to get the
>> cookie, as the application would need something it can interpret.
> Why can't you have a get_pkt_metadata that returns the "cookie" -
> which I would call it userdata or similar? What I'm trying to say is
> that we should try to keep it as generic as possible. For example, I
> wouldn't assume that the cookie is stored in pkt->udata64 in the
> application.
I agree to your suggestion. The only problem is in the asymmetry of how
we would set the "cookie" (or userdata) and get it back. Right now we
are passing this as a member in conf. Do you have any thoughts on that?
For a more meaningful approach, we could pass this as another argument
in create_session API. I was thinking of a scenario of supporting more
items. So added it in the structure.
Naming is open for suggestions. I'll use userdata instead.
>> And, even though it seems both are symmetric operations(get & set pkt
>> metadata), there are some minor differences in what they would do.
>> Set metadata would be setting metadata(udata64 member) in mbuf, while
>> get metadata is not exactly returning metadata. We use the actual
>> metadata to get something else(security session in the proposed
>> patch). That was the primary motive for adding "session_get" API.
> What they do exactly is left to the PMD implementation. From the
> user's perspective, it does not matter.
> There is no requirement that set pkt metadata will set the udata64
> member.
May be I misunderstood the terminology. "udata64" in mbuf was documented as
|RTE_STD_C11 union { void *userdata; /**< Can be used for external
metadata */ uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */ };|
I thought the metadata in set_pkt_metadata was coming from this. And we
were setting this member itself in ixgbe driver.
But yes, it makes sense not to expose it that way. The API can take mbuf
pointer and then, the PMD could dictate how it had set the metadata in
rx path.
>>
>> Thanks,
>> Anoob
>>
>> On 11/20/2017 05:42 PM, Radu Nicolau wrote:
>>> Hi,
>>>
>>>
>>> Why not have something similar to rte_security_set_pkt_metadata, for
>>> example:
>>>
>>> void *
>>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>> struct rte_mbuf *mb);
>>>
>>> and keep internally in the PMD all the required references. The
>>> returned value will be device-specific, so it's flexible enough to
>>> include anything required (just as void *params is in the
>>> set_pkt_metadata).
>>>
>>> I think it will make a cleaner and more consistent implementation.
>>>
>>>
>>> Regards,
>>>
>>> Radu
>>>
>>>
>>>
>>> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>>>> In case of inline protocol processed ingress traffic, the packet
>>>> may not
>>>> have enough information to determine the security parameters with
>>>> which
>>>> the packet was processed. In such cases, the application could
>>>> register
>>>> a cookie, which will be saved in the the security session.
>>>>
>>>> As the ingress packets are received in the application, it will have
>>>> some metadata set in the mbuf. Application can pass this metadata to
>>>> "rte_security_session_get" API to retrieve the security session. Once
>>>> the security session is determined, another driver call with the
>>>> security session will give the application the cookie it had
>>>> registered.
>>>>
>>>> The cookie will be registered while creating the security session.
>>>> Without the cookie, the selector check (SP-SA check) for the incoming
>>>> IPsec traffic won't be possible in the application.
>>>>
>>>> Application can choose what it should register as the cookie. It can
>>>> register SPI or a pointer to SA.
>>>>
>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>> ---
>>>> lib/librte_security/rte_security.c | 26
>>>> +++++++++++++++++++++++
>>>> lib/librte_security/rte_security.h | 30
>>>> +++++++++++++++++++++++++++
>>>> lib/librte_security/rte_security_driver.h | 34
>>>> +++++++++++++++++++++++++++++++
>>>> 3 files changed, 90 insertions(+)
>>>> <snip>
>>
>
I'll rework the patch to include your suggestions. I'll send a v2 after
doing this.
Thanks for the feedback,
Anoob
On 11/20/2017 7:09 PM, Anoob Joseph wrote:
>
> Hi
>
> See inline.
>
> On 20-11-2017 23:19, Radu Nicolau wrote:
>> Hi
>>
>>
>> On 11/20/2017 3:32 PM, Anoob wrote:
>>> Hi,
>>>
>>> Having something like "get_pkt_metadata" should be fine for inline
>>> protocol usage. But we will still need a "get cookie" call to get
>>> the cookie, as the application would need something it can interpret.
>> Why can't you have a get_pkt_metadata that returns the "cookie" -
>> which I would call it userdata or similar? What I'm trying to say is
>> that we should try to keep it as generic as possible. For example, I
>> wouldn't assume that the cookie is stored in pkt->udata64 in the
>> application.
> I agree to your suggestion. The only problem is in the asymmetry of
> how we would set the "cookie" (or userdata) and get it back. Right now
> we are passing this as a member in conf. Do you have any thoughts on
> that? For a more meaningful approach, we could pass this as another
> argument in create_session API. I was thinking of a scenario of
> supporting more items. So added it in the structure.
>
> Naming is open for suggestions. I'll use userdata instead.
I think keeping it in the conf is best, but it can be either way.
>>> And, even though it seems both are symmetric operations(get & set
>>> pkt metadata), there are some minor differences in what they would
>>> do. Set metadata would be setting metadata(udata64 member) in mbuf,
>>> while get metadata is not exactly returning metadata. We use the
>>> actual metadata to get something else(security session in the
>>> proposed patch). That was the primary motive for adding
>>> "session_get" API.
>> What they do exactly is left to the PMD implementation. From the
>> user's perspective, it does not matter.
>> There is no requirement that set pkt metadata will set the udata64
>> member.
> May be I misunderstood the terminology. "udata64" in mbuf was
> documented as
> |RTE_STD_C11 union { void *userdata; /**< Can be used for external
> metadata */ uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */ };|
>
> I thought the metadata in set_pkt_metadata was coming from this. And
> we were setting this member itself in ixgbe driver.
We're using it in the ixgbe because it is the most obvious choice when
there is only a small data set to be passed (an table index in this
case) but it was intended to allow the driver to implement any behavior
necessary.
>
> But yes, it makes sense not to expose it that way. The API can take
> mbuf pointer and then, the PMD could dictate how it had set the
> metadata in rx path.
>
>>>
>>> Thanks,
>>> Anoob
>>>
>>> On 11/20/2017 05:42 PM, Radu Nicolau wrote:
>>>> Hi,
>>>>
>>>>
>>>> Why not have something similar to rte_security_set_pkt_metadata,
>>>> for example:
>>>>
>>>> void *
>>>> rte_security_get_pkt_metadata(struct rte_security_ctx *instance,
>>>> struct rte_mbuf *mb);
>>>>
>>>> and keep internally in the PMD all the required references. The
>>>> returned value will be device-specific, so it's flexible enough to
>>>> include anything required (just as void *params is in the
>>>> set_pkt_metadata).
>>>>
>>>> I think it will make a cleaner and more consistent implementation.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Radu
>>>>
>>>>
>>>>
>>>> On 11/20/2017 10:31 AM, Anoob Joseph wrote:
>>>>> In case of inline protocol processed ingress traffic, the packet
>>>>> may not
>>>>> have enough information to determine the security parameters with
>>>>> which
>>>>> the packet was processed. In such cases, the application could
>>>>> register
>>>>> a cookie, which will be saved in the the security session.
>>>>>
>>>>> As the ingress packets are received in the application, it will have
>>>>> some metadata set in the mbuf. Application can pass this metadata to
>>>>> "rte_security_session_get" API to retrieve the security session. Once
>>>>> the security session is determined, another driver call with the
>>>>> security session will give the application the cookie it had
>>>>> registered.
>>>>>
>>>>> The cookie will be registered while creating the security session.
>>>>> Without the cookie, the selector check (SP-SA check) for the incoming
>>>>> IPsec traffic won't be possible in the application.
>>>>>
>>>>> Application can choose what it should register as the cookie. It can
>>>>> register SPI or a pointer to SA.
>>>>>
>>>>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>>>>> ---
>>>>> lib/librte_security/rte_security.c | 26
>>>>> +++++++++++++++++++++++
>>>>> lib/librte_security/rte_security.h | 30
>>>>> +++++++++++++++++++++++++++
>>>>> lib/librte_security/rte_security_driver.h | 34
>>>>> +++++++++++++++++++++++++++++++
>>>>> 3 files changed, 90 insertions(+)
>>>>> <snip>
>>>
>>
> I'll rework the patch to include your suggestions. I'll send a v2
> after doing this.
>
> Thanks for the feedback,
> Anoob
>
@@ -98,6 +98,32 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
return ret;
}
+struct rte_security_session *
+rte_security_session_get(struct rte_security_ctx *instance,
+ uint64_t mdata)
+{
+ struct rte_security_session *sess = NULL;
+
+ RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->session_get, NULL);
+ if (instance->ops->session_get(instance->device, mdata, &sess))
+ return NULL;
+
+ return sess;
+}
+
+uint64_t
+rte_security_cookie_get(struct rte_security_ctx *instance,
+ struct rte_security_session *sess)
+{
+ uint64_t cookie = 0;
+
+ RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->cookie_get, 0);
+ if (instance->ops->cookie_get(instance->device, sess, &cookie))
+ return 0;
+
+ return cookie;
+}
+
int
rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
struct rte_security_session *sess,
@@ -273,6 +273,8 @@ struct rte_security_session_conf {
/**< Configuration parameters for security session */
struct rte_crypto_sym_xform *crypto_xform;
/**< Security Session Crypto Transformations */
+ uint64_t cookie;
+ /**< Cookie registered by application */
};
struct rte_security_session {
@@ -327,6 +329,34 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
struct rte_security_session *sess);
/**
+ * Get the security session from the metadata set in mbuf.
+ *
+ * @param instance security instance
+ * @param mdata metadata set in mbuf during rx offload
+ * @return
+ * - On success, pointer to session
+ * - On failure, NULL
+ */
+struct rte_security_session *
+rte_security_session_get(struct rte_security_ctx *instance,
+ uint64_t mdata);
+
+/**
+ * Get the cookie set by application while creating the session. This could be
+ * used to identify the SA associated with the session.
+ *
+ * @param instance security instance
+ * @param sess security session
+ *
+ * @return
+ * - On success, cookie
+ * - On failure, 0
+ */
+uint64_t
+rte_security_cookie_get(struct rte_security_ctx *instance,
+ struct rte_security_session *sess);
+
+/**
* Updates the buffer with device-specific defined metadata
*
* @param instance security instance
@@ -107,6 +107,36 @@ typedef int (*security_session_stats_get_t)(void *device,
struct rte_security_stats *stats);
/**
+ * Get the security session from the metadata set in mbuf.
+ *
+ * @param device Crypto/eth device pointer
+ * @param mdata Metadata set in mbuf during rx offload
+ * @param sess Pointer to return the security session retrieved
+ *
+ * @return
+ * - Returns 0 if the security session was successfully retrieved.
+ * - Returns -EINVAL if input parameters are invalid.
+ */
+typedef int (*security_session_get_t)(void *device,
+ uint64_t mdata,
+ struct rte_security_session **sess);
+
+/**
+ * Get the cookie associated with the security session.
+ *
+ * @param device Crypto/eth device pointer
+ * @param sess Security session
+ * @param cookie Cookie associated with the security session
+ *
+ * @return
+ * - Returns 0 if the cookie was successfully retrieved.
+ * - Returns -EINVAL if input parameters are invalid.
+ */
+typedef int (*security_cookie_get_t)(void *device,
+ struct rte_security_session *sess,
+ uint64_t *cookie);
+
+/**
* Update the mbuf with provided metadata.
*
* @param sess Security session structure
@@ -143,6 +173,10 @@ struct rte_security_ops {
/**< Get security session statistics. */
security_session_destroy_t session_destroy;
/**< Clear a security sessions private data. */
+ security_session_get_t session_get;
+ /**< Get the security session associated with the metadata */
+ security_cookie_get_t cookie_get;
+ /**< Get the cookie associated with the security session */
security_set_pkt_metadata_t set_pkt_metadata;
/**< Update mbuf metadata. */
security_capabilities_get_t capabilities_get;