From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4BCDFA054F; Wed, 25 May 2022 12:04:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3BED440146; Wed, 25 May 2022 12:04:38 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by mails.dpdk.org (Postfix) with ESMTP id 2C2C5400EF for ; Wed, 25 May 2022 12:04:36 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 24P9xtWY028700; Wed, 25 May 2022 03:04:35 -0700 Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2170.outbound.protection.outlook.com [104.47.56.170]) by mx0a-0016f401.pphosted.com (PPS) with ESMTPS id 3g9jap00p8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 May 2022 03:04:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NREd0pvt8e4pOeDUIVv0DvkLeuIyHMXaAHHNdHD1R1h9mIyslmnuDtYzq+xpps0pz1gJGXpupdzHuCeIpbDbfXEIFRQ5FsPFy4/JIzadP7weY3pl/WwpWz4wtdzQNOgg2w3DgbnVQUR8nA/pziUnnIxOL4Tt1C7fZaAFesED5gfEPv6wK3UROSbg8/+1S0P2lqS7aqqyYmK9/I2tmp+edLFumX97bquiZwLNjMvGhTBkQIilYR/g8k/R1tJzrG7/PHMLZIK5fUgcr9NWw+jpYajLBk0uxEEBuiwUWNE77rSjvEJh4Gb1KWM/U5xQBr13sS64ZppEyq/J1Razu0QlSw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2dfy7MDIPGgeDyTVcl/PpivFP0et/yiZrtzqSXuU21w=; b=VnZ3cYt4l1Eab3OTjohv5pkpabxZltTI8w6TIzViRS+uqFekkgGkbZBTZH6cjLqEm9pC8N+QTPblQFkJMZ7QZeqc1TKd17V6T/OrCNOhCXhfPpDGGD9VkePtm5BR5BgxxO3l/cKq1B92Avr3El/rdtsRWKNtj5X0nsxLL36blfZE+ZKMfrjAAaaxFI2+e1t8HcBR0+qUIgvo0of86RHns64iNyWffHZRb+pzcv66de5Qm1l2Gby1k112tkoas7r7IHnn95gpojKcZctgntJNxC41xo2KDeOPKjJx5/P79OoNy+eAoZb7rjDLOEixsvCeFTuJwW6tIkqYhmCqN7LdOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2dfy7MDIPGgeDyTVcl/PpivFP0et/yiZrtzqSXuU21w=; b=GN0NO9FYlkOw2sk+HtMivg5ZL1Uyd4Ue9I8hWd0PngHg0jbhs+DTzgWa2cuCSju5iyS1tf5IvLf7yuPjs7FsAtA/JsS64YElIzS7V/b7W2UkolGgsLL3/D+51kmfiJFNJdC8Ti9iq5JiMZcSGlDcx9pKjNd/pPplXmzVst8c0j0= Received: from CO1PR18MB4714.namprd18.prod.outlook.com (2603:10b6:303:e9::18) by BY5PR18MB3219.namprd18.prod.outlook.com (2603:10b6:a03:1a9::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5293.13; Wed, 25 May 2022 10:04:27 +0000 Received: from CO1PR18MB4714.namprd18.prod.outlook.com ([fe80::4897:bb67:4456:c21b]) by CO1PR18MB4714.namprd18.prod.outlook.com ([fe80::4897:bb67:4456:c21b%3]) with mapi id 15.20.5293.013; Wed, 25 May 2022 10:04:27 +0000 From: Gowrishankar Muthukrishnan To: Brian Dooley , "dev@dpdk.org" CC: Akhil Goyal , Fan Zhang , Anoob Joseph , Jerin Jacob Kollanukkaran , Thomas Monjalon , Archana Muniganti Subject: RE: [EXT] [RFC] examples/fips_validation: add fips 140-3 acvp aes-cbc test Thread-Topic: [EXT] [RFC] examples/fips_validation: add fips 140-3 acvp aes-cbc test Thread-Index: AQHYbGQ8/OVPWM8pTky6qQLS/RbfFa0vQLiA Date: Wed, 25 May 2022 10:04:27 +0000 Message-ID: References: <20220520160554.495317-1-brian.dooley@intel.com> In-Reply-To: <20220520160554.495317-1-brian.dooley@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba2a219d-eed7-4947-6b0a-08da3e35f444 x-ms-traffictypediagnostic: BY5PR18MB3219:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: veq32x/X3hGU65ybPtEVmlG8QFyKu5SX7Sbs2cGm1Ivb2qk4WUVxrEslrkz0d2mmegHPR3dlOd7eW+wcNw2u/g4wh80BMvKHvKFWr/gM3QBGe1Fq3nPPcrk08NPdIx/ovNfGp/65FdcVABqf5z568cXMAkS4OWN2MRr84Ln2ld82VHN8CRkscNj9yTlwrkbgPBnJ6KNpx53MTocU0+qxBCKjbBWlFLir/gZ9daoBoPCDgLe98blJ9GD+sjssGmNnnSVsBAL372f/3q2V3M/tdFt+tsRlFto9c6qag9qDEnKmAadnSejmnUL/WhB5amjVJfdJixlYWdW5yuCJI0n0cnkCuFL8/yBUxRpmOGJlqNckRLvwSN3Og9Nw+Jb5+4jbXvd40SuV2a8ay/o2nZ/EvWelmzDTMatVURPMKV9vziTl8ik/ObyzbGeZqSdKm9gEX2eN0MjTj0AW7vcfw55Oq7Q6vxhdQmebuIiRLQfox4WRh/ktaVC7vuEnnZBt4xNlmZ4jqPOJIdb7p4iDNuYgY9yxB/ljiGo82PZ4gTNvuUJ0jHWYhx3QVmmchroElat8+RI3jkNfBdxu/I/cky1PT95j8X1GoJzzr9FxseXBxY79UEgICArf6PZ9395DSz++Hve2c+MquzycGxc0k6U6aZVWLpd37Y0wpm5Dk69fPIkXKX17QPEEtywrtWB5t2sCK2KmZXxmSrA+RyPiXwWSa3VbaE/2qiApYsaZt83FT/MG4q4Eq61z1EjDWS8QAupcp8mMcPZYYR1GWNfdXYIZwGoo/utu+FVSGWxs4xgbzjQ4zEXyRLUZBN7WTsM4uigzmet9xgQB6g4LLWeO0YtjBg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR18MB4714.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(86362001)(508600001)(107886003)(76116006)(64756008)(966005)(30864003)(9686003)(7696005)(6506007)(186003)(2906002)(33656002)(38100700002)(8936002)(53546011)(52536014)(38070700005)(26005)(66446008)(66556008)(66476007)(122000001)(8676002)(316002)(71200400001)(5660300002)(83380400001)(4326008)(19627235002)(54906003)(110136005)(66946007)(55016003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7yCBrvsAkIJwLGnVSRoIBuFBatToW6zGcknXgKEeZq20vryc+RIyTnf/FLi0?= =?us-ascii?Q?b7sw+K2TEpY6fRkxdMM1Vd8C9B5/z+1+UD/tfAU7G2n1rNhgsWKJh4RlPxb4?= =?us-ascii?Q?V5lZYpElcQhGIG1ekDfZv91yql5IXm+1VKtTdryYvgtv4ct3IZGxwlssLEy5?= =?us-ascii?Q?N6XNgKLKV7ihK12IV59qHVZFJ7gg/8fyQwmwG5PXvsZ34NvXZhuOEZ5sxD7m?= =?us-ascii?Q?yhZuKewJl/VRh4iXgNbX9auEzf/Tt2qIR9JemduU4R0V4PO+/ljW7ErIjVL1?= =?us-ascii?Q?aMUCchoOzv6aBCe20tn/loUvYP0btP1yEDqRDewCBekDNghbXPMLZK7rf+Xr?= =?us-ascii?Q?xQezNsczYD6urePcHdTQHN6dGPN68f9pnOr4kAsr4RJXod7fvhmk3U0F9Dyd?= =?us-ascii?Q?kDEXeaCpmjP2UNaLS76ZaCw+HiNnqZ6P/PZX4jSyu5lE8gMInocZTn80aoZP?= =?us-ascii?Q?UmyLuGNGqPdYhNf+8onYj1SqkJkj3juXFZic2Dx7pVKTpG0wzuN6mOnY66yq?= =?us-ascii?Q?hHnwuxDtJj2bWz26bIZurSOEIaztK2OqtQ3fpv6RVNhskZZizEl/OAq6LHnz?= =?us-ascii?Q?caRN5wHfkod7Yqx2pFVQ7xCkIa9m1vr47Ue7RytJs1I//b7s3v9ccCQF8k6d?= =?us-ascii?Q?eEkpcDr6WXrOnOCDqBU8sNgCksDV01x6bHfAqGt+A9noVulyaVrmjWbPJsSl?= =?us-ascii?Q?AnzAWUXQjjmhE95nm/PB9wxJkW2PRUEW3qmiuCMuCsYfBVUnnwuei6+XBUDF?= =?us-ascii?Q?oU1334z4UCT0auu2ddDaKU+9bMq/3LdPp4qEYPMs5eOYLEgUM69xvCos8bMp?= =?us-ascii?Q?ri2U7r9DZb07gYHYx7i9mm2KP/EpHVnKag1FYPujTyOFp6ebhHE8KWjcyQVk?= =?us-ascii?Q?7RyTsrPI/fD4k1rPRTJXeFa25znKx7Q5lONScAjjMth06uIyW3s1SJ7jm8bE?= =?us-ascii?Q?bzBYaV+baYAbengCvtdCIS5hTNPJaGdefpbTX1Ie9EDPeXpxDLyiLft50Hl7?= =?us-ascii?Q?8lLvHGL3fjwjXllpBccf/Wk2eXIf9x96YJ3PnJAfKry82pOXT+2W5EBNx7vU?= =?us-ascii?Q?2keiP71WBI+IyoYo1ZYiHEdiytCJ1gDDFuQqwr53mmgjmdEwWggt8hosUPnI?= =?us-ascii?Q?qNPWIjb6NXU0wvAx/nNwkPkyqTkUuPkc1+tOg0HGcvRggoqS2bH4EKrf3kqQ?= =?us-ascii?Q?Pdr64ll3JtJBqSARB3OQ29ICnGhrL4q1dw7OxX8pY/AgcSYKl1LxHbFUMcUS?= =?us-ascii?Q?SkBQMtcPuL5KQu0c1mf98eUnE+d8gbdwcx1DlC47XFB9JAmtPldYmZuXXGud?= =?us-ascii?Q?NHRdfa1mrwcbMyT3uQRXXo8iQ2kjNBa2oU8ddbCfy1rMyglwWJ+/HUeeElyj?= =?us-ascii?Q?/GBCMANAomL0pd+1/KcxN80hCY5D0jUs0F8Gdl4DwNt8KXWAJuTTKERCkchZ?= =?us-ascii?Q?mDZnu1Cqz5tmGhOTU9a/7t16Xz4zSbuyT4kE/nFU4eS+TyxkWqNDAFBmlnUT?= =?us-ascii?Q?pjxDtFTk4N5AzxdZsfNxdfEj8fTP+rGoG85H0Kz+bjMDChRW5RO4/7KUFEjV?= =?us-ascii?Q?3zoC5oy3VDZBsGzrSKw5z6RX/7EBDBwH69JH9rxYGtucUhtldKf+YqfxcWdB?= =?us-ascii?Q?ScVWsPUhVqxrQSV0wpT7OFlE4hEkShQC25Pw+eTLRCZBX0kVAENL8F955676?= =?us-ascii?Q?moUHdNKwwz5pbi7SQCI92M9YCU+0AYHcV458IKze+60MSUumBoU/NgMnYBOo?= =?us-ascii?Q?Z9G3YbWEpg=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR18MB4714.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba2a219d-eed7-4947-6b0a-08da3e35f444 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2022 10:04:27.8034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q1olh+7jq2HAms/WpHfLqZ57k2nO3FCd5RWkthjYWWrml9aS+lTB3bXJWsvOat3AxJW/rzu4xSKLEKjribn0HJxi6Dvcd7kycakaa8SGgN8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR18MB3219 X-Proofpoint-GUID: Jmrs0gdyj6tC-d2BnePnh3be9eGZQTIK X-Proofpoint-ORIG-GUID: Jmrs0gdyj6tC-d2BnePnh3be9eGZQTIK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-25_03,2022-05-23_01,2022-02-23_01 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Brian, Thanks for the RFC and PFA inline my comments. > -----Original Message----- > From: Brian Dooley > Sent: Friday, May 20, 2022 9:36 PM > To: dev@dpdk.org > Cc: Akhil Goyal ; Gowrishankar Muthukrishnan > ; Brian Dooley ; Fan > Zhang > Subject: [EXT] [RFC] examples/fips_validation: add fips 140-3 acvp aes-cb= c > test >=20 > External Email >=20 > ---------------------------------------------------------------------- > This RFC patch showcases an alternative approach to enable FIPS 140-3 > support in the DPDK fips_validation sample application. >=20 > The approach presented here takes advantage of an existing open source > library, libacvp,(https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__github.com_cisco_libacvp&d=3DDwIDAg&c=3DnKjWec2b6R0mOyPaz7xtfQ&r > =3DEAtr-g7yUFhtOio8r2Rtm13Aqe4WVp_S_gHpcu6KFVo&m=3DOr6tpEsPX87- > j0caOkxdpMd9nEJRSlAb4JusQjipu1g09R4MIPOTbu_XGke63me_&s=3DZnDDms > 0KubRYj4TCliLrDQ9IO5S27LVUJunrx3vbpUA&e=3D ) to generate the parsed test > cases instead of creating and maintaining a DPDK FIPS test file parser. I= n > addition call back functions are added to the dpdk-fips_validation applic= ation > to process the parsed test vectors and write back the results. >=20 libacvp carries its source code under Apache License v2. Would there be any license conflict to consume it as parser for fips_validation in DPDK ? https://github.com/cisco/libacvp/blob/main/LICENSE > This initial RFC patch contains the code to parse the FIPS 140-3 test fil= es with > libacvp library, and the AES-CBC test runner callback function implementa= tion > with most test types covered apart from MCT test. >=20 > Although a different approach has been proposed > (https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__patches.dpdk.org_project_dpdk_list_-3Fseries- > 3D22738&d=3DDwIDAg&c=3DnKjWec2b6R0mOyPaz7xtfQ&r=3DEAtr- > g7yUFhtOio8r2Rtm13Aqe4WVp_S_gHpcu6KFVo&m=3DOr6tpEsPX87- > j0caOkxdpMd9nEJRSlAb4JusQjipu1g09R4MIPOTbu_XGke63me_&s=3DOlrgMzf > QefOQwOunfPxgtFcKOid-8-mw1yQVv0_Ncv8&e=3D ), it has the disadvantage > of having to maintain the parsing code. >=20 We already have stabilized code and good number of parsers from Brandon ser= ies=20 (plus the one I am also topping up - AES_CBC, SHA etc), we can always exten= d the parsers=20 availability as and when needed. Extension also would not be too difficult = IMHO as its=20 base functions are ready for all sort of extensions (where the real work co= uld only be to manipulate with key words for test vectors). I am also thinking that, NIST will only make changes in a pace that its eco= system can also follow. So, we can certainly catch up in our releases. > For the sake of this RFC here is some information on how to modify and ru= n a > test case. >=20 > The libacvp library can be installed by following the Building instructio= ns in the > README of the libacvp repo as linked above. >=20 Also libacvp is not available in any of OS distributions (https://pkgs.org/= search/?q=3Dacvp). Though README is absolutely helping, proper documentation in the context of consuming it for fips_validation can help better. For eg, (a) What configure options required (at bare minimum) to support fips= app. (b) Versions of libcurl and openssl that is supported by libacvp comp= ilation (for fips app.) (c) cross compilation notes (d) source code url to download from etc. Cross compiling with dependent libs is difficult at times when the integrit= y is not tested=20 properly. Hence, DPDK fips_validation would require special instructions ap= art from=20 README IMHO. > An example test vector which we can call as our input.req: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__github.com_cisco_libacvp_blob_main_test_json_aes_aes.json&d=3DDwI > DAg&c=3DnKjWec2b6R0mOyPaz7xtfQ&r=3DEAtr- > g7yUFhtOio8r2Rtm13Aqe4WVp_S_gHpcu6KFVo&m=3DOr6tpEsPX87- > j0caOkxdpMd9nEJRSlAb4JusQjipu1g09R4MIPOTbu_XGke63me_&s=3DJR1nXo6 > 9fg3FQ64fRyNYYYTs1-YU8ziuU5epo0VdRcg&e=3D >=20 > The header acvVersion metadata at the start needs to been updated to the > following: >=20 > { > "acvVersion": "1.0", > "jwt": "NA", > "url": "NA", > "isSample": false, > "vectorSetUrls": ["NA"] > } Can we manipulate these fields within the app itself instead ? For eg, url should be NA anyway for the scope of using this library here. >=20 > With this RFC patch applied you can then run the dpdk-fips_validation as > follows: >=20 > ./dpdk-fips_validation --vdev=3Dcrypto_aesni_mb -- \ > --req-file input.req --rsp-file output.rsp --acvp >=20 > Please note the MCT tests in the input.req file will generate an incorrec= t > result set as the IV update part has yet to be implemented. > This will be addressed in next revision. >=20 Please give a check on entire results including AFT as well. I did json dif= f and learnt=20 atleast 1500 out of 2156 tests failed for AES_CBC while using this patch (i.e post tcId 285, many of tests failed including AFT). If it is not the c= ase for you, I can cross check once again if anything else going wrong, as none of tests= fail in same env and with same req file, while using native parser from Brandon. > Signed-off-by: Brian Dooley > --- > examples/fips_validation/fips_test_acvp.c | 183 > +++++++++++++++++++++ examples/fips_validation/fips_validation.h | 34 > ++++ > examples/fips_validation/main.c | 59 ++++--- > examples/fips_validation/meson.build | 9 + > 4 files changed, 260 insertions(+), 25 deletions(-) create mode 100644 > examples/fips_validation/fips_test_acvp.c >=20 > diff --git a/examples/fips_validation/fips_test_acvp.c > b/examples/fips_validation/fips_test_acvp.c > new file mode 100644 > index 0000000000..55f6b35a7d > --- /dev/null > +++ b/examples/fips_validation/fips_test_acvp.c > @@ -0,0 +1,183 @@ > +/* SPDX-License-Identifier: BSD-3-Clause > + * Copyright(c) 2022 Intel Corporation > + */ > + > +#include > +#include > +#include > +#include I find it not required for this patch, do we need this header for any other= purpose ? > +#include > +#include > +#include > + > +#include > +#include > + > +#include "fips_validation.h" > + > +#define IV_OFF (sizeof(struct rte_crypto_op) + sizeof(struct > +rte_crypto_sym_op)) > + > +static ACVP_RESULT logger(char *msg) > +{ > + printf("%s", msg); > + return ACVP_SUCCESS; > +} > + > +static int aes_cbc_handler(ACVP_TEST_CASE *test_case) { > + ACVP_SYM_CIPHER_TC *tc; > + struct rte_crypto_sym_xform xform =3D { 0 }; > + const struct rte_cryptodev_symmetric_capability *cap; > + struct rte_cryptodev_sym_capability_idx cap_idx; > + struct rte_crypto_cipher_xform *cipher_xform =3D &xform.cipher; > + struct rte_crypto_sym_op *sym =3D env.op->sym; > + struct fips_val val =3D {NULL, 0}; > + uint8_t *iv =3D rte_crypto_op_ctod_offset(env.op, uint8_t *, IV_OFF); > + uint16_t n_deqd; > + int ret; > + > + memset(&xform, 0, sizeof(xform)); > + > + tc =3D test_case->tc.symmetric; > + > + xform.type =3D RTE_CRYPTO_SYM_XFORM_CIPHER; > + > + cipher_xform->algo =3D RTE_CRYPTO_CIPHER_AES_CBC; > + cipher_xform->op =3D (tc->direction =3D=3D > ACVP_SYM_CIPH_DIR_ENCRYPT) ? > + RTE_CRYPTO_AEAD_OP_ENCRYPT : > + RTE_CRYPTO_AEAD_OP_DECRYPT; > + cipher_xform->key.data =3D tc->key; > + /* Check support for 128 bit key*/ > + if (tc->key_len % 8 =3D=3D 0) > + cipher_xform->key.length =3D 16; > + else > + cipher_xform->key.length =3D tc->key_len; > + > + if (cipher_xform->algo =3D=3D RTE_CRYPTO_CIPHER_AES_CBC) { > + cipher_xform->iv.length =3D tc->iv_len; > + cipher_xform->iv.offset =3D IV_OFF; > + } else { > + cipher_xform->iv.length =3D 0; > + cipher_xform->iv.offset =3D 0; > + } > + cap_idx.algo.cipher =3D cipher_xform->algo; > + cap_idx.type =3D RTE_CRYPTO_SYM_XFORM_CIPHER; > + > + cap =3D (env.dev_id, &cap_idx); > + if (!cap) { > + RTE_LOG(ERR, USER1, "Failed to get capability for cdev > %u\n", > + env.dev_id); > + return -EINVAL; > + } > + > + if (rte_cryptodev_sym_capability_check_cipher(cap, > + cipher_xform->key.length, > + cipher_xform->iv.length) !=3D 0) { > + RTE_LOG(ERR, USER1, "PMD %s key length %u IV length > %u\n", > + info.device_name, cipher_xform- > >key.length, > + cipher_xform->iv.length); > + return -EPERM; > + } > + > + env.sess =3D rte_cryptodev_sym_session_create(env.sess_mpool); > + if (!env.sess) > + return -ENOMEM; > + > + ret =3D rte_cryptodev_sym_session_init(env.dev_id, env.sess, > &xform, > + env.sess_priv_mpool); > + if (ret < 0) { > + RTE_LOG(ERR, PMD, "Error %i: Init session\n", ret); > + return ret; > + } > + > + if (env.op) > + rte_crypto_op_free(env.op); > + > + env.op =3D rte_crypto_op_alloc(env.op_pool, > + RTE_CRYPTO_OP_TYPE_SYMMETRIC); > + if (!env.op) > + ret =3D -ENOMEM; > + > + memcpy(iv, tc->iv, tc->iv_len); > + > + if (tc->direction =3D=3D ACVP_SYM_CIPH_DIR_ENCRYPT) { > + val.val =3D tc->pt; > + val.len =3D tc->pt_len; > + } else { /* Decrypt */ > + val.val =3D tc->ct; > + val.len =3D tc->ct_len; > + } > + > + ret =3D prepare_data_mbufs(&val); > + if (ret < 0) > + return ret; > + > + if (tc->direction =3D=3D ACVP_SYM_CIPH_DIR_ENCRYPT) { > + sym->cipher.data.length =3D tc->pt_len; > + } else { /* Decrypt */ > + sym->cipher.data.length =3D tc->ct_len; > + } > + > + rte_crypto_op_attach_sym_session(env.op, env.sess); > + > + sym->m_src =3D env.mbuf; > + sym->cipher.data.offset =3D 0; > + > + if (rte_cryptodev_enqueue_burst(env.dev_id, 0, &env.op, 1) < 1) { > + RTE_LOG(ERR, USER1, "Error: Failed enqueue\n"); > + return ret =3D -1; > + } > + > + do { > + struct rte_crypto_op *deqd_op[1]; > + > + n_deqd =3D rte_cryptodev_dequeue_burst(env.dev_id, 0, > deqd_op, > + 1); > + } while (n_deqd =3D=3D 0); > + > + rte_cryptodev_sym_session_clear(env.dev_id, env.sess); > + rte_cryptodev_sym_session_free(env.sess); > + > + val.val =3D NULL; > + > + ret =3D get_writeback_data(&val); > + if (ret < 0) > + return ret; > + > + if (tc->direction =3D=3D ACVP_SYM_CIPH_DIR_ENCRYPT) { > + memcpy(tc->ct, val.val, val.len); > + tc->ct_len =3D val.len; > + } else { /* Decrypt */ > + memcpy(tc->pt, val.val, val.len); > + tc->pt_len =3D val.len; > + } > + > + return ret; > +} > + Can we have common aes_cbc handler common for above prepare xform, session = creation and run test, writeback_data etc so that, these can be shared between native and library = parsers. Finally, If an end user of fips_validation app is reluctant to proceed with= libacvp for any reason, we will not have any parser to help him for FIPS 140-3, instead we can keep= Brandon approach as a=20 native fallback option and this patch can add support using external libacv= p library (as an option). Thanks, Gowrishankar