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 A4E1FA04BC; Fri, 9 Oct 2020 11:33:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 99CD21C239; Fri, 9 Oct 2020 11:33:27 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 38DE41C234; Fri, 9 Oct 2020 11:33:24 +0200 (CEST) IronPort-SDR: pFjAVspAs9QZRVMvAv4x+wxnBI8Iij1EEO+Brj4xTwZ+kuIIhevGGWbq1yvr7wFFcO4SG2+v7E 3fmd8LkVMbBA== X-IronPort-AV: E=McAfee;i="6000,8403,9768"; a="165578068" X-IronPort-AV: E=Sophos;i="5.77,354,1596524400"; d="scan'208";a="165578068" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2020 02:33:22 -0700 IronPort-SDR: OGJsWt06QMzeQZU5rZp4SNs1x4JyHm+6Pd+6uBYqkP0Rh5uIfD7XpjXJE+BPPBC9s7h18JRMJ6 q2/fW/sjjktw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,354,1596524400"; d="scan'208";a="328852685" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga002.jf.intel.com with ESMTP; 09 Oct 2020 02:33:22 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 9 Oct 2020 02:33:22 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 9 Oct 2020 02:33:21 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 9 Oct 2020 02:33:21 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.55) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 9 Oct 2020 02:33:21 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DRcjxaH234/TE2/WdbPTF61KznV40Y1RNIYBab/XudgOpDXx+q9EKjgh+1CWHHWwEs1jeDUbY+Uh4exTENMIN6wAsNkudidwztXBY7FZkptbnTxGJlXVeF0TIHQnvq3XoSi36StPic+ZqxD87TZVFmuPSp7RpI9t4iWW7hUPGKItzZlm5mi/Bu3k96OGdi9PUH0rGPv5xTK9VvGUd6htdlOmauh46Ajg8CoPmpaUa5etlmit5ga87k3f0XhZ154vUHXJ3WQu0jZS/b/lSPlSPXs8klvLKZ9oBwFWSOmriupSIq2ukZkKhPJurmvGWA4V/AEDiUItYBtG8qX1pvvQ5A== 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=T5HwJwVXPQDYtJU6AMbH5Let7ju8LZEw1sddMB5m01s=; b=lFcmtLL4x8jtocicO8QMs6PfAxnYGGh9DRuALcauGWrL0iFNyOSk+Soq5hXr7B0LSS3xH8owaVau+kYDnuOfQRdVwWFqJDIFhC7hPm7KxaW8N5fqy/tkM0StclIDqe1jIOmjuGbSR+XYCfci+bGAeRzC1TN3HB4j+exZn8xEbxSOP9PeBKwfMJjKFjo1twAOZryIFiH9Z8ANmDWSLtPkaVPduxSe/UsbK4f3QqFkSScRLlVq4Y/EAhj7HgyaFlVqqsWL8POqn/ELGt7uwvKxSIW50IH8TZJnO/1rAfxbPtdophcmXD0pn4EQ8SNrIonUkmvtPDktacmU975PUWDB+A== 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=T5HwJwVXPQDYtJU6AMbH5Let7ju8LZEw1sddMB5m01s=; b=f+bI4hlXD5CaMxuUQTAamqUSILSTZF4dSJWGBRbQQwlE3T9iFsfYZ3RR8N/4E9d2R1TRa4W/zRPw7E2r1C/3TtFjQsVnnJMIew4zlIAe4aDm24oIaiKyDHP85BaFOPrj/4O1MzwPG8sQoSEMU8g62i6Sy0SzMPSMmxVMe0Whbnc= Received: from BL0PR11MB3043.namprd11.prod.outlook.com (2603:10b6:208:33::19) by BL0PR11MB3443.namprd11.prod.outlook.com (2603:10b6:208:6c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Fri, 9 Oct 2020 09:33:20 +0000 Received: from BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239]) by BL0PR11MB3043.namprd11.prod.outlook.com ([fe80::11fa:a7fe:329d:9239%5]) with mapi id 15.20.3455.023; Fri, 9 Oct 2020 09:33:20 +0000 From: "Zhang, Roy Fan" To: Olivier Matz CC: "dev@dpdk.org" , "Kovacevic, Marko" , Akhil Goyal , "Kusztal, ArkadiuszX" , "stable@dpdk.org" , Anoob Joseph Thread-Topic: [PATCH 2/3] examples/fips_validation: ignore \r in input files Thread-Index: AQHWm7Q4Kcw8UFQAJkyqV8ey/1yPmamKQQZwgAAY/oCAAwz2AIAACm6AgAANLtCAABdHAIAAEX5AgAAdY4CAATfToA== Date: Fri, 9 Oct 2020 09:33:19 +0000 Message-ID: References: <20201006074143.31691-1-olivier.matz@6wind.com> <20201006074143.31691-3-olivier.matz@6wind.com> <20201006100901.GJ21395@platinum> <20201008092131.GU21395@platinum> <20201008113200.GW21395@platinum> <20201008141947.GY21395@platinum> In-Reply-To: <20201008141947.GY21395@platinum> Accept-Language: zh-Hans-HK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [95.44.220.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d02fa02-33e7-4733-04c2-08d86c365c09 x-ms-traffictypediagnostic: BL0PR11MB3443: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xr5l+CXmhh3mKQ4YazUrzS/zQI/90k/16OBh9B3lfZ8gk3Hb3skEkkOqmtVM/A9VtVapGGbY1CdwzsZE54jq/5Bw4B4ByjaK/rDo523/0kE01vcVpGj0qR6fAxaUpcuxV5/EpvdTzis1L4pi1E6dXhF9DDQ02InSXOqoZnYBv+7Ypfedi1rxZQoLe2JMcx5cQYbtmNz1wQD8rr24mxDrjCyqBNtXiH3qDXd69akfL3y6s2WW7DKIAXbdFXOa90nqWzsajDXKYo211inwIh1g2nlNszwhxEAQdTTlyPRQZl97QU2YrgeZLeGxrWNOV7kXQDT00qA6e8rZQMTrz6bqiZwfFiA6CLJvglCFdrOleITZsoUsFo+pch9LOhcZ/cRwvm+oRQkM0uKkX1d3MXSLww== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3043.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(30864003)(66946007)(66476007)(54906003)(66446008)(55016002)(33656002)(86362001)(6916009)(2906002)(52536014)(83080400001)(83380400001)(478600001)(5660300002)(966005)(64756008)(76116006)(66556008)(316002)(4326008)(6506007)(8676002)(9686003)(26005)(71200400001)(8936002)(53546011)(7696005)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: IZKDiPJlspTAi5yI+sk57oPYYLXox9YylP0IhjZQkx1UkBsW12ylBlVWJpc32r2qdjALzNEbGm7LIckY30kH6cImDWGM4rBGXAinTEdOfw5pb4GCcGCJ/XgBw3banuu/QNvBcf0n997Kv/iyluFZHMQ+2DceZFc6iSYlfILhaPsB8X5a9MPrlOrV2tdG5EzBx44qNbQGcy9XX+Qsrc1RbcoSb3C6uweFS5dUCpBcEwWtC0mpDb7w7Aq/DsOh4DRF6Ppk5k6mKztHrBwLnq16UtnrDylXGp+69ZTfKmTpyjrOJLI4DE36e338GsI5uAOV9OB9uenTyh22b/2S7OmZUzVLO2yb+YRiWuExqUoyGkEQqC3OAv/hyvSCoVJmltO1pZzzVOSsxEDAHvreq0cgjnBVqmrQER83ZTngpwFVLCxIHVp8KKpjDzRTSYyNcWAc793xC7KLX4sGcbE54JGjznQpB1lazOkC0ZIIOsqnEUka9MYFMD22Qa15J0VWeMqs5tct3xeSeMp+HJ9os5FjXfH2QlgNJ/n8NSVeJHNbM+6vkvfYwDgFN5YzCzHgtT2RPAkbRaloQnQ1yuyvoxwmuviuj91Bc9cx3ZELtN8K9jkRc48TCa8iRLDbQ9VIMOZglTb/6+hAf8xWtDpFcWI8mg== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3043.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d02fa02-33e7-4733-04c2-08d86c365c09 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 09:33:19.6446 (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: C+mvJz+LOBWctmJKnAeZuWO/OMcVZkw1XX/7bd4YnwzNLgCn2WKHts89hGsD1Uhifm7/PP6MivEZyth4FPPxyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3443 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/3] examples/fips_validation: ignore \r in input files 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" Hi,=20 I agree. Thanks a lot Olivier. Also thanks for the other 2 FIPS patches :-). Regards, Fan > -----Original Message----- > From: Olivier Matz > Sent: Thursday, October 8, 2020 3:20 PM > To: Zhang, Roy Fan > Cc: dev@dpdk.org; Kovacevic, Marko ; Akhil > Goyal ; Kusztal, ArkadiuszX > ; stable@dpdk.org; Anoob Joseph > > Subject: Re: [PATCH 2/3] examples/fips_validation: ignore \r in input fil= es >=20 > Hi Fan, >=20 > So if we cannot know which version removed the \r, I suggest to just > drop this patch. I thought it was a bug in the parser, but if it does > not happen with files matching the supported CAVS version, there is > nothing to fix. >=20 > What do you think? >=20 > Thanks, > Olivier >=20 >=20 > On Thu, Oct 08, 2020 at 12:41:11PM +0000, Zhang, Roy Fan wrote: > > Hi Olivier, > > > > Unfortunately I wanted to find the same document since forever. NIST > > did not provide this on their website. What I am sure is for CAVS 21.0 > > both the test vectors Intel used for testing and the ones provided by > > our customer for debugging did not have \r in the files. In 2018 we > > could find some sample request and response files from NIST website > > but I just checked and they are gone. > > > > Regards, > > Fan > > > > > -----Original Message----- > > > From: Olivier Matz > > > Sent: Thursday, October 8, 2020 12:32 PM > > > To: Zhang, Roy Fan > > > Cc: dev@dpdk.org; Kovacevic, Marko ; > Akhil > > > Goyal ; Kusztal, ArkadiuszX > > > ; stable@dpdk.org; Anoob Joseph > > > > > > Subject: Re: [PATCH 2/3] examples/fips_validation: ignore \r in input= files > > > > > > Hi Fan, > > > > > > Thank you for the clarification. One more question: do you know where= I > > > can find a description of the different FIPS CAVS versions? I would l= ike > > > to know from what version the \r has been removed. > > > > > > Thanks, > > > Olivier > > > > > > On Thu, Oct 08, 2020 at 10:24:48AM +0000, Zhang, Roy Fan wrote: > > > > Hi Olivier, > > > > > > > > Sorry I didn't state myself clear in the first place. > > > > > > > > My intention is '\r' check, or any future CAVS version specific cha= nge to > the > > > > application should be wrapped into a branch that is checked with > parsed > > > > version number. With this way the original application's behavior s= hould > > > > remain the same. > > > > > > > > The reason for that is we are having an issue right now that the > validation > > > > team is struggling with the limited test vectors and inconsistency > formatting > > > > between different FIPS CAVS versions. For example we still have FIP= S > TDES > > > test > > > > failing today due to the different test file versions. > > > > https://bugs.dpdk.org/show_bug.cgi?id=3D512 > > > > > > > > The solution is certainly far from pretty but should help to share = the > > > > maintenance effort amongst the contributors. > > > > > > > > The "FIPS_DEF_VERSION" can be removed of course. > > > > > > > > Regards, > > > > Fan > > > > > > > > > -----Original Message----- > > > > > From: Olivier Matz > > > > > Sent: Thursday, October 8, 2020 10:22 AM > > > > > To: Zhang, Roy Fan > > > > > Cc: dev@dpdk.org; Kovacevic, Marko ; > > > Akhil > > > > > Goyal ; Kusztal, ArkadiuszX > > > > > ; stable@dpdk.org; Anoob Joseph > > > > > > > > > > Subject: Re: [PATCH 2/3] examples/fips_validation: ignore \r in i= nput > files > > > > > > > > > > Hi, > > > > > > > > > > On Thu, Oct 08, 2020 at 08:50:25AM +0000, Zhang, Roy Fan wrote: > > > > > > Hi Olivier, > > > > > > > > > > > > Anood and us had the similar discussion. > > > > > > > > > > > > Can we change the sample application to parse version data inst= ead, > > > > > > and for the version specific code changes we will wrap them by = a > > > > > > branch to compare the parsed version and the expected version? > > > > > > (we probably should have done that long time ago). > > > > > > > > > > > > I drafted a code change to parse the version data, see if you t= hink it > > > > > > is ok? > > > > > > > > > > Thank you for your feedback. > > > > > > > > > > The code that gets the version looks good to me (I just have a > > > > > small comment, see below). However I'm not sure what to do with i= t. > > > > > > > > > > Do you mean we should return an error if the version is incorrect= ? Or > > > > > should we only skip '\r' for old versions? FIPS_DEF_VERSION is no= t > used > > > > > in your patch. In that case, I think it is a bit overkill. Do you= think > > > > > it is a problem to always drop '\r'? > > > > > > > > > > If you think we should not support files containing '\r', I'm fin= e > > > > > with it, I can drop this particular patch. > > > > > > > > > > > > > > > > > > > > > > diff --git a/examples/fips_validation/fips_validation.c > > > > > b/examples/fips_validation/fips_validation.c > > > > > > index 9bdf257b8..9b6518c92 100644 > > > > > > --- a/examples/fips_validation/fips_validation.c > > > > > > +++ b/examples/fips_validation/fips_validation.c > > > > > > @@ -98,7 +98,7 @@ fips_test_parse_header(void) > > > > > > uint32_t i; > > > > > > char *tmp; > > > > > > int ret; > > > > > > - int algo_parsed =3D 0; > > > > > > + int algo_parsed =3D 0, version_parsed =3D 0; > > > > > > time_t t =3D time(NULL); > > > > > > struct tm *tm_now =3D localtime(&t); > > > > > > > > > > > > @@ -107,6 +107,27 @@ fips_test_parse_header(void) > > > > > > return ret; > > > > > > > > > > > > for (i =3D 0; i < info.nb_vec_lines; i++) { > > > > > > + /* parse the version info */ > > > > > > + tmp =3D strstr(info.vec[i], "CAVS "); > > > > > > + if (tmp !=3D NULL) { > > > > > > + if (version_parsed !=3D 0) { > > > > > > + RTE_LOG(ERR, USER1, > > > > > > + "Multiple version data\n"); > > > > > > + return -1; > > > > > > + } > > > > > > + > > > > > > + tmp =3D tmp + sizeof("CAVS "); > > > > > > > > > > I think it should be strlen(), because sizeof() will contain > > > > > the '\0'. Or it could be sizeof() - 1. > > > > > > > > > > > + > > > > > > + if (strlen(tmp) >=3D MAX_VER_STRING_SIZE) { > > > > > > + RTE_LOG(ERR, USER1, "Version (%s) > too > > > > > long\n", > > > > > > + tmp); > > > > > > + return -1; > > > > > > + } > > > > > > + > > > > > > + strlcpy(info.version, tmp, > MAX_VER_STRING_SIZE); > > > > > > + version_parsed =3D 1; > > > > > > + } > > > > > > + > > > > > > if (!algo_parsed) { > > > > > > if (strstr(info.vec[i], "AESVS")) { > > > > > > algo_parsed =3D 1; > > > > > > diff --git a/examples/fips_validation/fips_validation.h > > > > > b/examples/fips_validation/fips_validation.h > > > > > > index 75fa555fa..b8c60c55f 100644 > > > > > > --- a/examples/fips_validation/fips_validation.h > > > > > > +++ b/examples/fips_validation/fips_validation.h > > > > > > @@ -15,6 +15,9 @@ > > > > > > #define MAX_BUF_SIZE 2048 > > > > > > #define MAX_STRING_SIZE 64 > > > > > > #define MAX_DIGEST_SIZE 64 > > > > > > +#define MAX_VER_STRING_SIZE 8 > > > > > > + > > > > > > +#define FIPS_DEF_VERSION "21.0" > > > > > > > > > > > > #define POSITIVE_TEST 0 > > > > > > #define NEGATIVE_TEST -1 > > > > > > @@ -155,6 +158,7 @@ struct sha_interim_data { > > > > > > }; > > > > > > > > > > > > struct fips_test_interim_info { > > > > > > + char version[MAX_VER_STRING_SIZE]; > > > > > > FILE *fp_rd; > > > > > > FILE *fp_wr; > > > > > > enum file_types file_type; > > > > > > > > > > > > > > > > > > Regards, > > > > > > Fan > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Olivier Matz > > > > > > > Sent: Tuesday, October 6, 2020 11:09 AM > > > > > > > To: Zhang, Roy Fan > > > > > > > Cc: dev@dpdk.org; Kovacevic, Marko > ; > > > > > Akhil > > > > > > > Goyal ; Kusztal, ArkadiuszX > > > > > > > ; stable@dpdk.org; Anoob Joseph > > > > > > > > > > > > > > Subject: Re: [PATCH 2/3] examples/fips_validation: ignore \r = in > input > > > files > > > > > > > > > > > > > > Hi Fan, > > > > > > > > > > > > > > On Tue, Oct 06, 2020 at 08:47:10AM +0000, Zhang, Roy Fan wrot= e: > > > > > > > > Hi Olivier, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Olivier Matz > > > > > > > > > Sent: Tuesday, October 6, 2020 8:42 AM > > > > > > > > > To: dev@dpdk.org > > > > > > > > > Cc: Kovacevic, Marko ; Akhil > Goyal > > > > > > > > > ; Zhang, Roy Fan > > > ; > > > > > > > Kusztal, > > > > > > > > > ArkadiuszX ; stable@dpdk.or= g > > > > > > > > > Subject: [PATCH 2/3] examples/fips_validation: ignore \r = in > input > > > files > > > > > > > > > > > > > > > > > > Some test vectors contain '\r' before '\n' (see link). Ig= nore > them. > > > > > > > > > > > > > > > > > > Link: https://www.openssl.org/docs/fips/testvectors-linux= - > 2007- > > > 10- > > > > > > > 10.tar.gz > > > > > > > > > Fixes: 3d0fad56b74a ("examples/fips_validation: add crypt= o > FIPS > > > > > > > application") > > > > > > > > > Cc: stable@dpdk.org > > > > > > > > > > > > > > > > > > Signed-off-by: Olivier Matz > > > > > > > > > --- > > > > > > > > > examples/fips_validation/fips_validation.c | 2 ++ > > > > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/examples/fips_validation/fips_validation.c > > > > > > > > > b/examples/fips_validation/fips_validation.c > > > > > > > > > index 13f763c9aa..858f581ba3 100644 > > > > > > > > > --- a/examples/fips_validation/fips_validation.c > > > > > > > > > +++ b/examples/fips_validation/fips_validation.c > > > > > > > > > @@ -33,6 +33,8 @@ get_file_line(void) > > > > > > > > > > > > > > > > > > if (loc >=3D MAX_LINE_CHAR - 1) > > > > > > > > > return -ENOMEM; > > > > > > > > > + if (c =3D=3D '\r') > > > > > > > > > + continue; > > > > > > > > > if (c =3D=3D '\n') > > > > > > > > > break; > > > > > > > > > line[loc++] =3D c; > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > The patch looks ok but the test file link you provided in t= he patch > is > > > > > CAVS > > > > > > > > 5.3. > > > > > > > > > > > > > > > > As mentioned in > > > > > > > > > https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html, > > > the > > > > > > > supported > > > > > > > > CAVS supported version is 21.0 (not latest one by newer tha= n > 5.3). > > > In > > > > > CAVS > > > > > > > > 21.0 test files there is no '\r' before '\n' (I suppose thi= s is for > > > Windows > > > > > > > > right). > > > > > > > > > > > > > > Thank you for your feedback. > > > > > > > > > > > > > > I'm ok to drop this patch from the patchset if you feel it's = useless, > or > > > > > > > I can update the commit log with the information you provide,= to > > > clarify > > > > > > > that it should not happen with the supported version of CAVS. > > > > > > > > > > > > > > Please let me know what you prefer. > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Olivier