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 7D702A0535; Tue, 4 Feb 2020 23:00:29 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EEB111C205; Tue, 4 Feb 2020 23:00:28 +0100 (CET) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 2162E1C1E6 for ; Tue, 4 Feb 2020 23:00:27 +0100 (CET) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1iz6Eg-0006md-HF; Tue, 04 Feb 2020 17:00:12 -0500 Date: Tue, 4 Feb 2020 16:59:48 -0500 From: Neil Horman To: Akhil Goyal Cc: Ferruh Yigit , Thomas Monjalon , "Ananyev, Konstantin" , "Trahe, Fiona" , David Marchand , Anoob Joseph , "Kusztal, ArkadiuszX" , "dev@dpdk.org" , "Richardson, Bruce" , "Mcnamara, John" , "dodji@seketeli.net" , Andrew Rybchenko , "aconole@redhat.com" , "bluca@debian.org" , "ktraynor@redhat.com" Message-ID: <20200204215948.GC13754@hmswarspite.think-freely.org> References: <20191220152058.10739-1-david.marchand@redhat.com> <666f2cc7-0906-7a07-a582-87800f321a00@intel.com> <7566080.EvYhyI6sBW@xps> <78e8ecf2-2239-897e-e34c-aee7227f3d42@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks 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" On Tue, Feb 04, 2020 at 10:16:56AM +0000, Akhil Goyal wrote: > Hi, > > On 2/3/2020 5:09 PM, Thomas Monjalon wrote: > > > 03/02/2020 10:30, Ferruh Yigit: > > >> On 2/2/2020 2:41 PM, Ananyev, Konstantin wrote: > > >>> 02/02/2020 14:05, Thomas Monjalon: > > >>>> 31/01/2020 15:16, Trahe, Fiona: > > >>>>> On 1/30/2020 8:18 PM, Thomas Monjalon wrote: > > >>>>>> 30/01/2020 17:09, Ferruh Yigit: > > >>>>>>> On 1/29/2020 8:13 PM, Akhil Goyal wrote: > > >>>>>>>> > > >>>>>>>> I believe these enums will be used only in case of ASYM case which is > > experimental. > > >>>>>>> > > >>>>>>> Independent from being experiment and not, this shouldn't be a > > problem, I think > > >>>>>>> this is a false positive. > > >>>>>>> > > >>>>>>> The ABI break can happen when a struct has been shared between the > > application > > >>>>>>> and the library (DPDK) and the layout of that memory know differently > > by > > >>>>>>> application and the library. > > >>>>>>> > > >>>>>>> Here in all cases, there is no layout/size change. > > >>>>>>> > > >>>>>>> As to the value changes of the enums, since application compiled with > > old DPDK, > > >>>>>>> it will know only up to '6', 7 and more means invalid to the application. > > So it > > >>>>>>> won't send these values also it should ignore these values from library. > > Only > > >>>>>>> consequence is old application won't able to use new features those > > new enums > > >>>>>>> provide but that is expected/normal. > > >>>>>> > > >>>>>> If library give higher value than expected by the application, > > >>>>>> if the application uses this value as array index, > > >>>>>> there can be an access out of bounds. > > >>>>> > > >>>>> [Fiona] All asymmetric APIs are experimental so above shouldn't be a > > problem. > > >>>>> But for the same issue with sym crypto below, I believe Ferruh's > > explanation makes > > >>>>> sense and I don't see how there can be an API breakage. > > >>>>> So if an application hasn't compiled against the new lib it will be still using > > the old value > > >>>>> which will be within bounds. If it's picking up the higher new value from > > the lib it must > > >>>>> have been compiled against the lib so shouldn't have problems. > > >>>> > > >>>> You say there is no ABI issue because the application will be re-compiled > > >>>> for the updated library. Indeed, compilation fixes compatibility issues. > > >>>> But this is not relevant for ABI compatibility. > > >>>> ABI compatibility means we can upgrade the library without recompiling > > >>>> the application and it must work. > > >>>> You think it is a false positive because you assume the application > > >>>> "picks" the new value. I think you miss the case where the new value > > >>>> is returned by a function in the upgraded library. > > >>>> > > >>>>> There are also no structs on the API which contain arrays using this > > >>>>> for sizing, so I don't see an opportunity for an appl to have a > > >>>>> mismatch in memory addresses. > > >>>> > > >>>> Let me demonstrate where the API may "use" the new value > > >>>> RTE_CRYPTO_AEAD_CHACHA20_POLY1305 and how it impacts the > > application. > > >>>> > > >>>> Once upon a time a DPDK application counting the number of devices > > >>>> supporting each AEAD algo (in order to find the best supported algo). > > >>>> It is done in an array indexed by algo id: > > >>>> int aead_dev_count[RTE_CRYPTO_AEAD_LIST_END]; > > >>>> The application is compiled with DPDK 19.11, > > >>>> where RTE_CRYPTO_AEAD_LIST_END = 3. > > >>>> So the size of the application array aead_dev_count is 3. > > >>>> This binary is run with DPDK 20.02, > > >>>> where RTE_CRYPTO_AEAD_CHACHA20_POLY1305 = 3. > > >>>> When calling rte_cryptodev_info_get() on a device QAT_GEN3, > > >>>> rte_cryptodev_info.capabilities.sym.aead.algo is set to > > >>>> RTE_CRYPTO_AEAD_CHACHA20_POLY1305 (= 3). > > >>>> The application uses this value: > > >>>> ++ aead_dev_count[info.capabilities.sym.aead.algo]; > > >>>> The application is crashing because of out of bound access. > > >>> > > >>> I'd say this is an example of bad written app. > > >>> It probably should check that returned by library value doesn't > > >>> exceed its internal array size. > > >> > > >> +1 > > >> > > >> Application should ignore values >= MAX. > > > > > > Of course, blaming the API user is a lot easier than looking at the API. > > > Here the API has RTE_CRYPTO_AEAD_LIST_END which can be understood > > > as the max value for the application. > > > Value ranges are part of the ABI compatibility contract. > > > It seems you expect the application developer to be aware that > > > DPDK could return a higher value, so the application should > > > check every enum values after calling an API. CRAZY. > > > > > > When we decide to announce an ABI compatibility and do some marketing, > > > everyone is OK. But when we need to really make our ABI compatible, > > > I see little or no effort. DISAPPOINTING. > > > > This is not to blame the user or to do less work, this is more sane approach > > that library provides the _END/_MAX value and application uses it as valid range > > check. > > > > > > > >> Do you suggest we don't extend any enum or define between ABI breakage > > releases > > >> to be sure bad written applications not affected? > > > > > > I suggest we must consider not breaking any assumption made on the API. > > > Here we are breaking the enum range because nothing mentions _LIST_END > > > is not really the absolute end of the enum. > > > The solution is to make the change below in 20.02 + backport in 19.11.1: > > > > > > - _LIST_END > > > + _LIST_END, /* an ABI-compatible version may increase this value */ > > > + _LIST_MAX = _LIST_END + 42 /* room for ABI-compatible additions */ > > > }; > > > > > > > What is the point of "_LIST_MAX" here? > > > > Application should know the "_LIST_END" of when it has been compiled for the > > valid range check. Next time it is compiled "_LIST_END" may be different value > > but same logic applies. > > > > When "_LIST_END" is missing, application can't protect itself, in that case > > library should send only the values application knows when it is compiled, this > > means either we can't extend our enum/defines until next ABI breakage, or we > > need to do ABI versioning to the functions that returns an enum each time enum > > value extended. > > > > I believe it is saner to provide _END/_MAX values to the application to use. And > > if required comment them to clarify the expected usage. > > > > But in above suggestion application can't use or rely on "_LIST_MAX", it doesn't > > mean anything to application. > > > > Can we have something like > enum rte_crypto_aead_algorithm { > RTE_CRYPTO_AEAD_AES_CCM = 1, > /**< AES algorithm in CCM mode. */ > RTE_CRYPTO_AEAD_AES_GCM, > /**< AES algorithm in GCM mode. */ > RTE_CRYPTO_AEAD_LIST_END, > /**< List end for 19.11 ABI compatibility */ > RTE_CRYPTO_AEAD_CHACHA20_POLY1305, > /**< Chacha20 cipher with poly1305 authenticator */ > RTE_CRYPTO_AEAD_LIST_END_2011 > /**< List end for 20.11 ABI compatibility */ > }; > > And in 20.11 release we alter the RTE_CRYPTO_AEAD_LIST_END to the end and remove RTE_CRYPTO_AEAD_LIST_END_2011 > > I believe it will be ok for any application which need to use the chacha poly assume that this algo is > Experimental and will move to formal list in 20.11. This can be documented in the documentation. > I believe there is no way to add a new enum as experimental so far. This way we can formalize this > requirement as well. > > I believe this way effect of ABI breakage will be nullified. > Thats not really helpful though, in that libabigail will then complain that you've aliased an old ennumeration name in the ABI to a new name. A better solution would be do one of the following: a) add an API call - something like rte_crypto_get_max_alg(), which returns at run time the maximum number of algorithms available, so that the application is forced to learn that number at run time, rather than at compile time b) Modify the API such that you pass in an algorithm name rather than an index value defined by an ennumeration. You may also add an API call that dumps all the available strings back to the user. a) would be nice, but it would still require an ABI change, which is less than optimal b) is nice because it gives you flexibility in how you search for algs - if you want to add a new alg, you just update your internal tables with a new name string, and applications get get its information by querying based on that string, rather than an index. b is also nice because it can just superscede the existing implementation (i.e. the current implementation remains unchanged, but only supports the current, existing algs), if you want to get the new algs, you use the new API calls (which can also find the already existing algs), and at some point in the future we can just deprecate the old API. Neil > > -Akhil > > > > Then *_LIST_END values could be ignored by libabigail with such a change. > > > > > > If such a patch is not done by tomorrow, I will have to revert > > > Chacha-Poly commits before 20.02-rc2, because > > > > > > 1/ LIST_END, without any comment, means "size of range" > > > 2/ we do not blame users for undocumented ABI changes > > > 3/ we respect the ABI compatibility contract > > > > > > >