On 24-Jul-24 12:20 PM, Akhil Goyal wrote:
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.
RFC treats it as a "four octet value" - there is no endianness until
it's treated like an integer, which it never is. Even if it code it's
being stored and passed as an unsigned 32bit integer it is never
evaluated as such so its endianness doesn't matter.
I agree that we should have it everywhere as "uint8_t salt[4]" but that
implies API changes and it doesn't change how the bytes are stored, so
the patch will still be wrong.
On 03/07/2024 18:58, Akhil Goyal wrote:
-----Original Message-----
From: Akhil Goyal <gak...@marvell.com>
<mailto:gak...@marvell.com>
Sent: Friday, March 15, 2024 12:42 AM
To: Akhil Goyal <gak...@marvell.com>
<mailto:gak...@marvell.com> ; Chaoyong He
<chaoyong...@corigine.com>
<mailto:chaoyong...@corigine.com> ; dev@dpdk.org <mailto:dev@dpdk.org>
Cc: oss-driv...@corigine.com <mailto:oss-
driv...@corigine.com> ; Shihong Wang <shihong.w...@corigine.com>
<mailto:shihong.w...@corigine.com> ;
sta...@dpdk.org <mailto:sta...@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.w...@corigine.com> <mailto:shihong.w...@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: sta...@dpdk.org <mailto:sta...@dpdk.org>
Signed-off-by: Shihong Wang
<shihong.w...@corigine.com> <mailto:shihong.w...@corigine.com>
Reviewed-by: Chaoyong He
<chaoyong...@corigine.com> <mailto:chaoyong...@corigine.com>
Acked-by: Akhil Goyal <gak...@marvell.com>
<mailto:gak...@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
