From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DA4B8A00C2; Thu, 23 Apr 2020 09:54:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 025D21D16A; Thu, 23 Apr 2020 09:54:44 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 315611D167; Thu, 23 Apr 2020 09:54:41 +0200 (CEST) IronPort-SDR: uOq3Au2yTuhFEthfd8NAeNgmCCJH0Rh6vCm7Go7Y53LzsGP0lzfpEhZw+NucfWw2E9aioWRg30 ccdfgufnRDrA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2020 00:54:41 -0700 IronPort-SDR: BZL/PwIcJGMBfSq0mvsjL7uBtf2bF03XqKIUAS8TXVjUUfqdXmq58Htl3BCLnPjkBujGqtY6gV 4C2LSGlkoROA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,306,1583222400"; d="scan'208";a="402837415" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga004.jf.intel.com with ESMTP; 23 Apr 2020 00:54:40 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 23 Apr 2020 00:54:29 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 23 Apr 2020 00:54:29 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 23 Apr 2020 00:54:29 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.51) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 23 Apr 2020 00:54:24 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QOnK7BuvJwb3ubKY3yqR6PtxigNHF1UycD3KyzanA+/zR2STQT5EvioIue1C1NCYQkYBpjopd50ian3I/WfFgvLfk9edDzLdVrdn6F/Z93hvEP+GWwFXjSI90nQgOBlKo1nulN7nAKWE9FfUfoagicVVxJ2JZgMumV71ZUl+N4aUvb8z0cqRQBiKOxdDUJQwOeZiwPp0J8nmk2waZVrc5rKqJq0LO/ZNiGbMd4ISz//N401WVgUDIaImHrnEYacr07drVV8DRZTHOQWm82KrB13rnszbxbGtEkp54kURgJwJ30dptJ/q283hirOz0zh4pGcOlZTQdScjj0TeKGWkMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qZoW8Etlozmz4VCDYK5Zfo9x09D/OgVtV4a6DrNuyJU=; b=X9KYFRjaeLHVQHAgVuIqnSG6nvGsfOqagCTZRcbO7C3HuIoJmi6on0p04zDHnojBmEWeo7muKvHr5Su5uQSR3EEAU5slwdrJebWikX2aL0F9xjvxXKfFuOlq+Ewze2dCphy2TdTLQ2TLp8HPq35bQsBAaxPiUokmCxzu+0n4fKDWeikBzWKjyzvpJkpEe/slaihDLsPTL3HmwSmTrPHIBJKhBbVPDsgTV+ukU6t1buvMLN0NRVvZAw4ENhfqilRnv8Uj6zqgvpCeKyqV32Dc7DxK5tdxDKT/BqJnWDh1fwHxtDk6qr4cbEqUaY64fkLncWyJbZG21rVJDZfHBO17TQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qZoW8Etlozmz4VCDYK5Zfo9x09D/OgVtV4a6DrNuyJU=; b=tr3V07teHUYV/InoKrrRv2vTsVZg68TTQp+ZxbFXAQ50q6Ax2ch04FV9/nXab3u1mDJmKnWeVccV+ZMRmAa3INwf6k2P6yZ51rPQbIAFWqOuoc19Mvvx1UnYcRM1PbS7D3j/4rre0BzodiymS8CfFZ8zwgPh58Al16rKu/XznYI= Received: from DM6PR11MB3308.namprd11.prod.outlook.com (2603:10b6:5:d::22) by DM6PR11MB4505.namprd11.prod.outlook.com (2603:10b6:5:1dd::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Thu, 23 Apr 2020 07:54:08 +0000 Received: from DM6PR11MB3308.namprd11.prod.outlook.com ([fe80::81a4:905d:a9b8:44af]) by DM6PR11MB3308.namprd11.prod.outlook.com ([fe80::81a4:905d:a9b8:44af%5]) with mapi id 15.20.2921.030; Thu, 23 Apr 2020 07:54:08 +0000 From: "Ananyev, Konstantin" To: Anoob Joseph , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "Doherty, Declan" , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] security: fix crash at accessing non-implemented ops Thread-Index: AQHWGSTLO6APWAgcfEqbxThOaNZf1KiGUA6g Date: Thu, 23 Apr 2020 07:54:08 +0000 Message-ID: References: <20200422235158.24497-1-konstantin.ananyev@intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dad07c9a-31da-4433-fcef-08d7e75b80df x-ms-traffictypediagnostic: DM6PR11MB4505: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3308.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(346002)(136003)(376002)(366004)(396003)(39860400002)(316002)(4326008)(186003)(55016002)(9686003)(66556008)(66476007)(66946007)(76116006)(64756008)(26005)(52536014)(66446008)(7696005)(2906002)(53546011)(6506007)(71200400001)(54906003)(81156014)(15650500001)(110136005)(8936002)(33656002)(86362001)(478600001)(5660300002)(966005); DIR:OUT; SFP:1102; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7KIYRGuIJ2dn94cHhVepR6nRDQncl6GhTgRlQwCfkyI2qrhEaPVzERMb3bxSgw0CDVRfO5C0XLDP8HJ8u76OyGRgix8IsA6lekn4UWfmx0eDabw2Aa5jzFeObPwzOdoAxTzn63JK7YkToROdfcBqPonDX+b7RAte6mwii3M/yv0t5f54CNl/e1r9K/QsXntZaubhgE0WABKcwL3sWTNXJoAymMnqVV0pfSabFtu4KM+jTGnZvX0LARRpaIIsc0rniS/3eblZFABXmx2ap484bQVgd91vGnjiZVWuFQ6ofAV+YVh2b41KovYv6xvtUCQi3QbxtkHqIe17ce2nSPX07J/KP4xAkCbnKSeeJuP1RWKLpunG8QC5o9RYpBQr/zg2+StSyAWkz73lPZXm01Qx8VWYccRfm6M3vvBFRL+a3QFPGixBOnWCMyRffCV1RJkKX2elvnAkBbf+rsQLZStgzrXBJkK3NxpVq+LS+e9BQVnOmBLzcY1Hs3Z/vTecORH0xjoXcQ0JpXL7V1uST8+xSQ== x-ms-exchange-antispam-messagedata: atZXTetjXoBxuoCKqmpMJ7FDJQYPZUWZzFIW6QaNpFBPimcYHQsGGGZ0ogI684IZao2aVayooOQf3jCEBgn0IIfSWp7q5nQxiLSk3xmdeg39n3WABuP1jvP00i/Uv1q3mjlptbb75G5XkFV1zm1pTg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dad07c9a-31da-4433-fcef-08d7e75b80df X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 07:54:08.5098 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 96Tkp/ZEj57blphb604c3hpK2CTclL6HHA81fBfn8rc037MyLlzd7ZcFjJLEvbVq7PLtIYh75cWWJaF1rhGfCECvjDf5Cs2pd0oVRBkyZds= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4505 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH] security: fix crash at accessing non-implemented ops X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >=20 > Hi Konstantin, >=20 > These are data path ops and so it will be better if we can avoid such che= cks in the datapath. The same is done in ethdev also. AFAIK, get_userdata is an *optional* dev-ops function that can be used by = data-path. So far there was no strict requirement for the rte_security PMDs to *always= * implement it. So what you guys did is a silent change of public API behaviour. As result ixgbe, (and probably some others rte_security PMDs) stopped worki= ng properly. I don't see any point in these changes, but if you'd like to do that, at least our usual procedure has to be followed: 1. Send and RFC to get an agreement with rte_security PMDs maintainers (one= release ahead) 2. send a deprecation note (one release ahead) 3. change the behaviour of the public API 4. update release notes=20 AFAIK 1), 2), 4) wasn't done. So I think right now we need to revert original behaviour. >=20 > http://code.dpdk.org/dpdk/v20.02/source/lib/librte_ethdev/rte_ethdev.h#L4= 372 >=20 > Datapath functions in cryptodev (enqueue/dequeue) doesn't even have such = checks. > http://code.dpdk.org/dpdk/v20.02/source/lib/librte_cryptodev/rte_cryptode= v.h#L962 That's a different story: rx_burst/tx_burst, enqueue/dequeue are mandatory dev-ops functions that have to be implemented by each ethdev/cryptodev API. >=20 >=20 > Thanks, > Anoob >=20 > > -----Original Message----- > > From: dev 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 > > > > Subject: [dpdk-dev] [PATCH] security: fix crash at accessing non-implem= ented > > ops > > > > Valid checks for optional function pointers inside dev-ops were disable= d by > > undefined macro. > > > > Fixes: b6ee98547847 ("security: fix verification of parameters") > > > > Signed-off-by: Konstantin Ananyev > > --- > > 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/r= te_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 =3D 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