> >
> > 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.
> >
Applied the series to dpdk-next-crypto
As suggested
Hi,
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
> ; sta...
Hi Fan,
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.
What do you think?
Thanks,
Olivier
On Thu, Oct 08, 2020 at 12:4
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 fi
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 like
to know from what version the \r has been removed.
Thanks,
Olivier
On Thu, Oct 08, 2020 at 10:24:48AM +, Zhang, Roy Fan wrote:
> Hi Olivier
Hi Olivier,
Sorry I didn't state myself clear in the first place.
My intention is '\r' check, or any future CAVS version specific change to the
application should be wrapped into a branch that is checked with parsed
version number. With this way the original application's behavior should
remain t
Hi,
On Thu, Oct 08, 2020 at 08:50:25AM +, Zhang, Roy Fan wrote:
> Hi Olivier,
>
> Anood and us had the similar discussion.
>
> Can we change the sample application to parse version data instead,
> and for the version specific code changes we will wrap them by a
> branch to compare the parsed
Hi Olivier,
Anood and us had the similar discussion.
Can we change the sample application to parse version data instead,
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 ag
Hi Fan,
On Tue, Oct 06, 2020 at 08:47:10AM +, Zhang, Roy Fan wrote:
> 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 ; sta
Hi Olivier,
The patch looks ok but the test file link you provided in the 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 than
5.3). In CAVS 21.0 test files there is no '\r'
Some test vectors contain '\r' before '\n' (see link). Ignore them.
Link: https://www.openssl.org/docs/fips/testvectors-linux-2007-10-10.tar.gz
Fixes: 3d0fad56b74a ("examples/fips_validation: add crypto FIPS application")
Cc: sta...@dpdk.org
Signed-off-by: Olivier Matz
---
examples/fips_validat
11 matches
Mail list logo
