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 0EBD8A04FA; Thu, 6 Feb 2020 10:34:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3B40C1C0AD; Thu, 6 Feb 2020 10:34:27 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id CF16E1C0AA for ; Thu, 6 Feb 2020 10:34:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580981665; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=atq8tCzkz9yrSN9jV8LZknh26Sn5RU9tzeg+OUw9BKE=; b=Oy0i3LiAg0fVN6/OwmOXGdqEgVVwXxPqzxWTAfGkgbdSmjNHE48M+ThSpySlcaH0JZV03L /I2cpblTDxjU8L4DOlXlavEwQamfSjLtVa+CFz4niZg8HE2E9zwzW71WcKvZGBgV3rG51u gL9JwrbGeNgc/fJmxFkYxGr6ygOxkg0= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-w-_OEj-PN-y9rkl6XNHY-w-1; Thu, 06 Feb 2020 04:34:21 -0500 Received: by mail-vk1-f197.google.com with SMTP id i123so1729954vkg.8 for ; Thu, 06 Feb 2020 01:34:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0iw4sh2fnFjqTe4xLCKSd2yapwSXdan5XQ1h9n7m6Uo=; b=mEOmLmBe19JDX3vquQwcHr7UhcxJNjoDlb5NLTDFF/By87wtOinRfCu4WGnZvJ+5E8 PK2wZk8Y/V0SIti0oAl5c0Ofu8hfiMLg9MHdpwui4/GzNTtV0MKSeiLyuDajpHuJaY3B h3srbkjdUQSFz9i+57tjWqn/lqtpxIJ+A42ZanCkzX2CVnaRwKGp0K5mxoaJngBw5L6l CU6tWjbWXuk9Wmi7RbPWgCSXcLR3JQh8lv9RgWNesVz9FDF4Pz/dGjw0B4iOp59Jt/W2 0chJGycFJuLxTcW5NvxwA03me67HFAoY6mQnHg/CH1/IugHNZV1xswqa/KJrfFss6PC8 +XTQ== X-Gm-Message-State: APjAAAXz89MVkNh7hJlEAfiCw+h9uUnLXkOwPpNmyTQaW5oxTwA9HjaC kOwEDZeYm+TUqinthi3nGoc90MPn6lUB+r/p1NvdeOBLMDIhFLRoZx4OoDZ5dQ4uh1BWOzA29yQ 1n7A4PSTl6yWoYqo5Epo= X-Received: by 2002:a67:905:: with SMTP id 5mr1190896vsj.105.1580981660625; Thu, 06 Feb 2020 01:34:20 -0800 (PST) X-Google-Smtp-Source: APXvYqxtpxtKPVg1iuAM3nVY+EhnJN87bRdvqmDsHG8R+1WSzzWo8Ca+spiTlFUrWud/aGsctJpJ8aZiodpGWG4r/YU= X-Received: by 2002:a67:905:: with SMTP id 5mr1190883vsj.105.1580981660282; Thu, 06 Feb 2020 01:34:20 -0800 (PST) MIME-Version: 1.0 References: <20200122105222.3758-1-ssardar@amd.com> <45170712.MN2xkq1pzW@xps> In-Reply-To: <45170712.MN2xkq1pzW@xps> From: David Marchand Date: Thu, 6 Feb 2020 10:34:09 +0100 Message-ID: To: Thomas Monjalon Cc: "Kumar, Ravi1" , "Sardar, Shamsher singh" , "dev@dpdk.org" , Akhil Goyal , dodji@seketeli.net X-MC-Unique: w-_OEj-PN-y9rkl6XNHY-w-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2 1/2] crypto/ccp: sha3 support enabling in ccp 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 Wed, Feb 5, 2020 at 11:22 PM Thomas Monjalon wrote= : > 05/02/2020 13:24, Akhil Goyal: > > > For series, > > > Acked-by: Ravi Kumar > > > > > > > > > > >From: Sardar Shamsher Singh > > > > > > > >sha3 support enabled in AMD-CCP crypto controller > > > > > > > >Signed-off-by: Sardar Shamsher Singh > > > >--- > > Change patch title and description as below > > cryptodev: fix missing SHA3 algo strings > > > > SHA3 support was added earlier but algo strings were > > missing. This patch add the missing strings. > > > > Fixes: 1df800f89518 ("crypto/ccp: support SHA3 family") > > Cc: stable@dpdk.org > > > > Signed-off-by: Sardar Shamsher Singh > > Acked-by: Ravi Kumar > > Acked-by: Akhil Goyal > > > > Applied to dpdk-next-crypto > > Sorry I must drop this patch because it triggers an ABI warning: > [C]'const char* rte_crypto_auth_algorithm_strings[]' was changed at rte= _crypto_sym.h:320:1: > size of symbol changed from 168 to 232 This is still not clear to me, but here is how I understand the issue. An exposed array (and its size) ends up in both the shared library and the final binary data section. [dmarchan@wsfd-netdev66 dpdk]$ readelf -sW ~/builds/build-gcc-shared/app/dpdk-test-crypto-perf |grep rte_crypto_auth_algorithm_strings 86: 00000000004141a0 168 OBJECT GLOBAL DEFAULT 24 rte_crypto_auth_algorithm_strings@DPDK_20.0 (4) 308: 00000000004141a0 168 OBJECT GLOBAL DEFAULT 24 rte_crypto_auth_algorithm_strings@@DPDK_20.0 [dmarchan@wsfd-netdev66 dpdk]$ readelf -sW ~/builds/build-gcc-shared/lib/librte_cryptodev.so |grep rte_crypto_auth_algorithm_strings 57: 000000000000b220 168 OBJECT GLOBAL DEFAULT 23 rte_crypto_auth_algorithm_strings@@DPDK_20.0 158: 000000000000b220 168 OBJECT GLOBAL DEFAULT 23 rte_crypto_auth_algorithm_strings At runtime, the linker chooses to rewire all access to the final binary data section, not the shared library local representation. Now, if we update the array size, the shared library code is built with the assumption of the increased size. But at runtime with an "old" binary, the shared library code runs with a shorter array, with potential out of bound access. Interesting article: https://developers.redhat.com/blog/2019/05/06/how-c-array-sizes-become-part= -of-the-binary-interface-of-a-library/ --=20 David Marchand