DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@amd.com,
	 stephen@networkplumber.org, mattias.ronnblom@ericsson.com,
	stable@dpdk.org,  Kai Ji <kai.ji@intel.com>,
	Slawomir Mrozowicz <slawomirx.mrozowicz@intel.com>,
	 Tomasz Kulasek <tomaszx.kulasek@intel.com>,
	Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>,
	 Pablo de Lara <pablo.de.lara.guarch@intel.com>,
	 Michal Kobylinski <michalx.kobylinski@intel.com>
Subject: Re: [PATCH 4/6] crypto/openssl: fix 3DES-CTR with big endian CPUs
Date: Thu, 24 Oct 2024 15:10:01 +0200	[thread overview]
Message-ID: <CAJFAV8xz9UTjztK9aHm_xjFfZ_uXe9wE_k-ySTD=R5u4UJWeng@mail.gmail.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F816@smartserver.smartshare.dk>

On Thu, Oct 24, 2024 at 2:55 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: David Marchand [mailto:david.marchand@redhat.com]
> > Sent: Thursday, 24 October 2024 14.06
> >
> > Caught by code review.
> >
> > Don't byte swap unconditionally (assuming that CPU is little endian is
> > wrong). Instead, convert from big endian to cpu and vice versa.
>
> Yes looks like a bug.
> I wonder if this PMD has more similar bugs...
> grep bswap drivers/crypto/openssl/* says no.
>
> > @@ -110,9 +111,9 @@ ctr_inc(uint8_t *ctr)
> >  {
> >       uint64_t *ctr64 = (uint64_t *)ctr;
> >
> > -     *ctr64 = __builtin_bswap64(*ctr64);
> > +     *ctr64 = rte_be_to_cpu_64(*ctr64);
> >       (*ctr64)++;
> > -     *ctr64 = __builtin_bswap64(*ctr64);
> > +     *ctr64 = rte_cpu_to_be_64(*ctr64);
> >  }
>
> But that's not all.
>
> There may be an alignment bug too; the way it is used in process_openssl_cipher_des3ctr(), "ctr" is not guaranteed to be uint64_t aligned.
>
> How about this instead:
>
> ctr_inc(void *ctr)
> {
>         uint64_t ctr64 = rte_be_to_cpu_64(*(unaligned_uint64_t *)ctr);
>         ctr64++;
>         *(unaligned_uint64_t *)ctr = rte_cpu_to_be_64(ctr64);
> }
>
> Or this:
>
> ctr_inc(void *ctr)
> {
>         uint64_t ctr64;
>
>         memcpy(&ctr64, ctr, sizeof(uint64_t));
>         ctr64 = rte_be_to_cpu_64(ctr64);
>         ctr64++;
>         ctr64 = rte_cpu_to_be_64(ctr64);
>         memcpy(ctr, &ctr64, sizeof(uint64_t));
> }
>
> Or use a union in process_openssl_cipher_des3ctr() to ensure it's uint64_t aligned.

Or declare ctr as a uint64_t in process_openssl_cipher_des3ctr
directly, and remove this casting.


-- 
David Marchand


  reply	other threads:[~2024-10-24 13:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24 12:05 [PATCH 0/6] Clean up many __builtin_* in drivers David Marchand
2024-10-24 12:05 ` [PATCH 1/6] devtools: handle multiple pattern for skipping files David Marchand
2024-10-24 12:05 ` [PATCH 2/6] devtools: forbid use of builtin helpers David Marchand
2024-10-24 16:40   ` Stephen Hemminger
2024-10-24 12:05 ` [PATCH 3/6] common/dpaax: use prefetch macros David Marchand
2024-10-24 16:40   ` Stephen Hemminger
2024-10-24 12:05 ` [PATCH 4/6] crypto/openssl: fix 3DES-CTR with big endian CPUs David Marchand
2024-10-24 12:54   ` Morten Brørup
2024-10-24 13:10     ` David Marchand [this message]
2024-10-24 13:17       ` David Marchand
2024-10-24 13:30         ` David Marchand
2024-10-24 14:21           ` Morten Brørup
2024-10-24 12:05 ` [PATCH 5/6] drivers: use branch prediction macros David Marchand
2024-10-24 16:41   ` Stephen Hemminger
2024-10-24 12:05 ` [PATCH 6/6] drivers: use bitops API instead of compiler builtins David Marchand
2024-10-24 12:25   ` Morten Brørup

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='CAJFAV8xz9UTjztK9aHm_xjFfZ_uXe9wE_k-ySTD=R5u4UJWeng@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=danielx.t.mrzyglod@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=kai.ji@intel.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=mb@smartsharesystems.com \
    --cc=michalx.kobylinski@intel.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=slawomirx.mrozowicz@intel.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --cc=tomaszx.kulasek@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).