DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <gakhil@marvell.com>
To: Radu Nicolau <radu.nicolau@intel.com>,
	"Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>,
	Chaoyong He <chaoyong.he@corigine.com>,
	"dev@dpdk.org" <dev@dpdk.org>, Anoob Joseph <anoobj@marvell.com>,
	Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
	Gagandeep Singh <g.singh@nxp.com>, Kai Ji <kai.ji@intel.com>,
	Brian Dooley <brian.dooley@intel.com>,
	Jack Bond-Preston <jack.bond-preston@foss.arm.com>,
	"pablo.de.lara.guarch@intel.com" <pablo.de.lara.guarch@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"suanmingm@nvidia.com" <suanmingm@nvidia.com>
Cc: "oss-drivers@corigine.com" <oss-drivers@corigine.com>,
	Shihong Wang <shihong.wang@corigine.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem
Date: Thu, 25 Jul 2024 10:19:09 +0000	[thread overview]
Message-ID: <CO6PR18MB4484540956C6085AF10B3D17D8AB2@CO6PR18MB4484.namprd18.prod.outlook.com> (raw)
In-Reply-To: <3a675000-b050-4a92-baa2-9a704c889d4e@intel.com>

> 
> On 25-Jul-24 5:47 AM, Akhil Goyal wrote:
> >> On 24-Jul-24 2:04 PM, Akhil Goyal wrote:
> >>>> 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.
> >>>>>>
> >>>>> 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.
> >>> The endianness matters the moment it is stored as uint32_t in ipsec_sa
> >>> It means the value is stored in CPU endianness in that integer unless it is
> >> specified.
> >>
> >> What matters is that the four byte value in the key ends up in the
> >> memory in the same order, and that was always the case before the patch,
> >> regardless of the endianness of the CPU because load and store
> >> operations are not affected by endianness. With the patch the same four
> >> bytes from the configuration file will be stored differently in memory
> >> depending on the CPU. There is no need to fix the endianness of the
> >> salt, just as there is no need to fix the byte order of the key itself.
> >>
> > When a uint32 is used, there is no clarity whether it is in BE or LE.
> > So that is where the confusion comes.
> > For any new person, uint32 means it is in CPU byte order.
> > This patch tried to address that but it failed to address all the cases.
> > So my simple suggestion is instead of fixing the byte order at every place,
> > Lets just change the ipsec_sa->salt as rte_be32_t from uint32_t and revert this
> patch.
> > This will make things clear.
> > I am suggesting to convert this uint32_t to rte_be32_t for library as well for salt.
> > This change is not swapping anything, but making things explicitly clear that salt
> is in BE.
> 
> I agree with the suggestion of using rte_be32_t and reverting the patch.

Can you send a patch with both the changes?
> 
> (I still think it would be even better to use uint8_t[4] to reflect that
> it is a four byte value with no endianness but that's just IMHO, the
> important thing is to revert the patch that broke the functionality)
> 
That can be for next release in library.

  reply	other threads:[~2024-07-25 10:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-11  2:49 [PATCH 0/2] fix IPSec " Chaoyong He
2024-03-11  2:49 ` [PATCH 1/2] examples/ipsec-secgw: fix SA salt " Chaoyong He
2024-03-13 18:33   ` [EXTERNAL] " Akhil Goyal
2024-03-14  1:41     ` Chaoyong He
2024-03-14  2:00   ` [PATCH v2] " Chaoyong He
2024-03-14 18:17     ` [EXTERNAL] " Akhil Goyal
2024-03-14 19:11       ` Akhil Goyal
2024-07-03 17:58         ` Akhil Goyal
2024-07-23 16:04           ` Medvedkin, Vladimir
2024-07-23 16:57             ` Akhil Goyal
2024-07-24 10:59               ` Radu Nicolau
2024-07-24 11:20                 ` Akhil Goyal
2024-07-24 11:33                   ` Radu Nicolau
2024-07-24 13:04                     ` Akhil Goyal
2024-07-24 14:44                       ` Radu Nicolau
2024-07-25  4:47                         ` Akhil Goyal
2024-07-25 10:16                           ` Radu Nicolau
2024-07-25 10:19                             ` Akhil Goyal [this message]
2024-03-11  2:49 ` [PATCH 2/2] net/nfp: fix data " Chaoyong He
2024-03-13 15:39   ` Ferruh Yigit
2024-03-12 10:37 ` [PATCH 0/2] fix IPSec " Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO6PR18MB4484540956C6085AF10B3D17D8AB2@CO6PR18MB4484.namprd18.prod.outlook.com \
    --to=gakhil@marvell.com \
    --cc=anoobj@marvell.com \
    --cc=brian.dooley@intel.com \
    --cc=chaoyong.he@corigine.com \
    --cc=dev@dpdk.org \
    --cc=g.singh@nxp.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jack.bond-preston@foss.arm.com \
    --cc=kai.ji@intel.com \
    --cc=ndabilpuram@marvell.com \
    --cc=oss-drivers@corigine.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=radu.nicolau@intel.com \
    --cc=shihong.wang@corigine.com \
    --cc=stable@dpdk.org \
    --cc=suanmingm@nvidia.com \
    --cc=vladimir.medvedkin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).