DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>,
	Anoob Joseph <anoobj@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	"Doherty, Declan" <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [PATCH] security: fix crash at accessing non-implemented ops
Date: Thu, 23 Apr 2020 08:28:58 +0000	[thread overview]
Message-ID: <BYAPR11MB3301B55ADE8E14CCAA913E179AD30@BYAPR11MB3301.namprd11.prod.outlook.com> (raw)
In-Reply-To: <94481e37-1ab7-95f1-8c8a-cfdb281095ea@partner.samsung.com>


> W dniu 23.04.2020 o 06:07, Anoob Joseph pisze:
> > Hi Konstantin,
> >
> > These are data path ops and so it will be better if we can avoid such checks in the datapath. The same is done in ethdev also.
> >
> > https://protect2.fireeye.com/url?k=d44931cf-89d2cdac-d448ba80-0cc47a31cdbc-
> 8281a62b4c91d848&q=1&u=http%3A%2F%2Fcode.dpdk.org%2Fdpdk%2Fv20.02%2Fsource%2Flib%2Flibrte_ethdev%2Frte_ethdev.h%23L43
> 72
> >
> > Datapath functions in cryptodev (enqueue/dequeue) doesn't even have such checks.
> > https://protect2.fireeye.com/url?k=51324200-0ca9be63-5133c94f-0cc47a31cdbc-
> 11f88758fc12c996&q=1&u=http%3A%2F%2Fcode.dpdk.org%2Fdpdk%2Fv20.02%2Fsource%2Flib%2Flibrte_cryptodev%2Frte_cryptodev.h%
> 23L962
> >
> >
> > Thanks,
> > Anoob
> 
> Hi Konstantine,
> 
> It's my fault. Sorry.
> 
> These checks need to be disabled in non-debug code, so they should be
> wrapped in a macro. It's just not the valid macro.
> The discussion about rte_debug mode is ongoing
> (https://patchwork.dpdk.org/patch/68815/)
> and currently the v2 version of patches is prepared to gather
> maintainers opinion.
> 
> After the rte_debug is introduced the proper macro to use will be
> RTE_DEBUG_SECURITY.
> 
> Until then, the RTE_DEBUG macro can stay as like Anoob mentioned the
> checks will have impact on dataplane performance.
> 
> If you want to enable this code, please use CFLAGS="-DRTE_DEBUG"

Really? So what we have to tell now to our customers?
"Yes, rte_security is broken and can easily crash your app.
But we might fix it in future versions... or maybe not.
For now just recompile our source with that flag enabled?"
Obviously this is not an option.
It is a bug and it is a stopper for 20.05 release.
It has to be fixed asap. 


> 
> >
> >> -----Original Message-----
> >> From: dev <dev-bounces@dpdk.org> On Behalf Of Konstantin Ananyev
> >> Sent: Thursday, April 23, 2020 5:22 AM
> >> To: dev@dpdk.org
> >> Cc: akhil.goyal@nxp.com; declan.doherty@intel.com; Konstantin Ananyev
> >> <konstantin.ananyev@intel.com>
> >> Subject: [dpdk-dev] [PATCH] security: fix crash at accessing non-implemented
> >> ops
> >>
> >> Valid checks for optional function pointers inside dev-ops were disabled by
> >> undefined macro.
> >>
> >> Fixes: b6ee98547847 ("security: fix verification of parameters")
> >>
> >> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >> ---
> >>   lib/librte_security/rte_security.c | 4 ----
> >>   1 file changed, 4 deletions(-)
> >>
> >> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte_security.c
> >> index d475b0977..b65430ce2 100644
> >> --- a/lib/librte_security/rte_security.c
> >> +++ b/lib/librte_security/rte_security.c
> >> @@ -107,11 +107,9 @@ rte_security_set_pkt_metadata(struct rte_security_ctx
> >> *instance,
> >>   			      struct rte_security_session *sess,
> >>   			      struct rte_mbuf *m, void *params)  { -#ifdef
> >> RTE_DEBUG
> >>   	RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, set_pkt_metadata, -
> >> EINVAL,
> >>   			-ENOTSUP);
> >>   	RTE_PTR_OR_ERR_RET(sess, -EINVAL);
> >> -#endif
> >>   	return instance->ops->set_pkt_metadata(instance->device,
> >>   					       sess, m, params);
> >>   }
> >> @@ -121,9 +119,7 @@ rte_security_get_userdata(struct rte_security_ctx
> >> *instance, uint64_t md)  {
> >>   	void *userdata = NULL;
> >>
> >> -#ifdef RTE_DEBUG
> >>   	RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, get_userdata, NULL,
> >> NULL); -#endif
> >>   	if (instance->ops->get_userdata(instance->device, md, &userdata))
> >>   		return NULL;
> >>
> >> --
> >> 2.17.1
> >
> --
> 
> Lukasz Wojciechowski
> Principal Software Engineer
> 
> Samsung R&D Institute Poland
> Samsung Electronics
> Office +48 22 377 88 25
> l.wojciechow@partner.samsung.com


  reply	other threads:[~2020-04-23  8:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 23:51 Konstantin Ananyev
2020-04-23  0:11 ` Ananyev, Konstantin
2020-04-23  7:58   ` Lukasz Wojciechowski
2020-04-23  4:07 ` Anoob Joseph
2020-04-23  7:54   ` Ananyev, Konstantin
2020-04-23  8:06     ` Lukasz Wojciechowski
2020-04-23  8:11       ` Ananyev, Konstantin
2020-04-23  8:22       ` Ananyev, Konstantin
2020-04-23  9:09     ` Anoob Joseph
2020-04-23 10:54       ` Ananyev, Konstantin
2020-04-23 11:23         ` Anoob Joseph
2020-04-23 12:55           ` Akhil Goyal
2020-04-23 13:30             ` Lukasz Wojciechowski
2020-04-23 13:47             ` Ananyev, Konstantin
2020-04-23 14:08               ` Akhil Goyal
2020-04-23 14:48                 ` Ananyev, Konstantin
2020-04-23  8:00   ` Lukasz Wojciechowski
2020-04-23  8:28     ` Ananyev, Konstantin [this message]
2020-04-23 15:10 ` [dpdk-dev] [PATCH v2] " Konstantin Ananyev
2020-04-23 15:51   ` Akhil Goyal
2020-04-23 16:08     ` Anoob Joseph
2020-04-23 16:14       ` Akhil Goyal
2020-04-23 16:29         ` Lukasz Wojciechowski
     [not found]   ` <CGME20200423162615eucas1p2224e9313aa640f755cf226649d093bb9@eucas1p2.samsung.com>
2020-04-23 16:25     ` [dpdk-dev] [PATCH] test/security: enable tests for " Lukasz Wojciechowski
2020-05-09 21:47       ` Akhil Goyal
2020-05-11 10:15         ` Lukasz Wojciechowski

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=BYAPR11MB3301B55ADE8E14CCAA913E179AD30@BYAPR11MB3301.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=l.wojciechow@partner.samsung.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).