RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem

[Akhil Goyal <gakhil@marvell.com>]

> 
> On 23-Jul-24 5:57 PM, Akhil Goyal wrote:
> >> Hi all,
> >>
> >> This patch breaks ipsec tests with ipsec-secgw:
> >>
> >>
> >> ./examples/ipsec-secgw/test/run_test.sh -4 trs_aesctr_sha1
> >> ...
> >> ERROR: ./examples/ipsec-secgw/test/linux_test.sh failed for
> dst=192.168.31.14,
> >> sz=1
> >>   test IPv4 trs_aesctr_sha1 finished with status 1
> >> ERROR  test trs_aesctr_sha1 FAILED
> >>
> > The patch seems to be correct.
> > Please check endianness in the PMD you are testing.
> 
> In my opinion salt should not be affected by endianness and it should be
> used as it is in the key parameter. I think the patch is wrong to make
> it CPU endianness dependent before being passed to the PMDs, any PMD
> that needs the endianness swapped should do it in the PMD code. Indeed
> it's passed around as a 32 bit integer but it's not used as such, and
> when it's actually used it should be evaluated as a byte array.
> 
> https://datatracker.ietf.org/doc/html/rfc4106#section-4
> https://datatracker.ietf.org/doc/html/rfc4106#section-8.1

As per the rfc, it should be treated as byte order(i.e. big endian).
But here the problem is we treat it as uint32_t which makes it CPU endian when stored in ipsec_sa struct.
The keys are stored as an array of uint8_t, so keys are stored in byte order(Big endian).

So either we save salt as "uint8_t salt[4]" or do a conversion of cpu_to_be
So that when it is stored in PMD/HW, and we convert it from uint32_t to uint_8 *, there wont be issue.

> 
> >
> >
> >>
> >>
> >> On 03/07/2024 18:58, Akhil Goyal wrote:
> >>
> >>
> >>
> >>
> >>
> >> 		-----Original Message-----
> >> 		From: Akhil Goyal <gakhil@marvell.com>
> >> <mailto:gakhil@marvell.com>
> >> 		Sent: Friday, March 15, 2024 12:42 AM
> >> 		To: Akhil Goyal <gakhil@marvell.com>
> >> <mailto:gakhil@marvell.com> ; Chaoyong He
> >> 		<chaoyong.he@corigine.com>
> >> <mailto:chaoyong.he@corigine.com> ; dev@dpdk.org <mailto:dev@dpdk.org>
> >> 		Cc: oss-drivers@corigine.com <mailto:oss-
> >> drivers@corigine.com> ; Shihong Wang <shihong.wang@corigine.com>
> >> <mailto:shihong.wang@corigine.com> ;
> >> 		stable@dpdk.org <mailto:stable@dpdk.org>
> >> 		Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix
> >> SA salt
> >> 		endianness problem
> >>
> >>
> >> 			Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec-
> >> secgw: fix SA salt
> >> 			endianness problem
> >>
> >>
> >> 				From: Shihong Wang
> >> <shihong.wang@corigine.com> <mailto:shihong.wang@corigine.com>
> >>
> >> 				The SA salt of struct ipsec_sa is a CPU-endian
> >> u32 variable, but it’s
> >> 				value is stored in an array of encryption or
> >> authentication keys
> >> 				according to big-endian. So it maybe need to
> >> convert the endianness
> >> 				order to ensure that the value assigned to the
> >> SA salt is CPU-endian.
> >>
> >> 				Fixes: 50d75cae2a2c ("examples/ipsec-secgw:
> >> initialize SA salt")
> >> 				Fixes: 9413c3901f31 ("examples/ipsec-secgw:
> >> support additional algorithms")
> >> 				Fixes: 501e9c226adf ("examples/ipsec-secgw:
> >> add AEAD parameters")
> >> 				Cc: stable@dpdk.org <mailto:stable@dpdk.org>
> >>
> >> 				Signed-off-by: Shihong Wang
> >> <shihong.wang@corigine.com> <mailto:shihong.wang@corigine.com>
> >> 				Reviewed-by: Chaoyong He
> >> <chaoyong.he@corigine.com> <mailto:chaoyong.he@corigine.com>
> >>
> >>
> >> 			Acked-by: Akhil Goyal <gakhil@marvell.com>
> >> <mailto:gakhil@marvell.com>
> >>
> >> 			Applied to dpdk-next-crypto
> >>
> >>
> >> 		The patch is pulled back from dpdk-next-crypto.
> >> 		This change may cause all the PMDs to fail these cases.
> >> 		Would need acks from PMDs.
> >>
> >>
> >> 	Applied to dpdk-next-crypto
> >> 	No update from PMD owners.
> >> 	Applying it before RC2 so that we have time for fixes if needed.
> >>
> >>
> >> --
> >> Regards,
> >> Vladimir