[dpdk-dev v4 1/2] eal: Add mem equal and non-equal to prevent timing attacks memcmp.

[dpdk-dev v4 1/2] eal: Add mem equal and non-equal to prevent timing attacks memcmp.

[Kai Ji]

Bugzilla ID: 1773
Cc: stable@dpdk.org

[0] https://bugs.dpdk.org/show_bug.cgi?id=1773

Signed-off-by: Kai Ji <kai.ji@intel.com>
---
 lib/eal/include/rte_memory.h | 68 ++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/lib/eal/include/rte_memory.h b/lib/eal/include/rte_memory.h
index dcc0e69cfe..bbdef8e939 100644
--- a/lib/eal/include/rte_memory.h
+++ b/lib/eal/include/rte_memory.h
@@ -746,6 +746,74 @@ __rte_experimental
 void
 rte_memzero_explicit(void *dst, size_t sz);
 
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Constant-time memory inequality comparison.
+ *
+ * This function compares two memory regions in constant time, making it
+ * resistant to timing side-channel attacks. The execution time depends only
+ * on the length parameter, not on the actual data values being compared.
+ *
+ * This is particularly important for cryptographic operations where timing
+ * differences could leak information about secret keys, passwords, or other
+ * sensitive data.
+ *
+ * @param a
+ *   Pointer to the first memory region to compare
+ * @param b
+ *   Pointer to the second memory region to compare
+ * @param n
+ *   Number of bytes to compare
+ * @return
+ *   false if the memory regions are identical, true if they differ
+ */
+__rte_experimental
+static inline bool
+rte_memneq_consttime(const void *a, const void *b, size_t n)
+{
+	const volatile uint8_t *pa = (const volatile uint8_t *)a;
+	const volatile uint8_t *pb = (const volatile uint8_t *)b;
+	uint8_t result = 0;
+	size_t i;
+
+	for (i = 0; i < n; i++)
+		result |= pa[i] ^ pb[i];
+
+	return result != 0;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Constant-time memory equality comparison.
+ *
+ * This function compares two memory regions in constant time, making it
+ * resistant to timing side-channel attacks. The execution time depends only
+ * on the length parameter, not on the actual data values being compared.
+ *
+ * This is particularly important for cryptographic operations where timing
+ * differences could leak information about secret keys, passwords, or other
+ * sensitive data.
+ *
+ * @param a
+ *   Pointer to the first memory region to compare
+ * @param b
+ *   Pointer to the second memory region to compare
+ * @param n
+ *   Number of bytes to compare
+ * @return
+ *   true if the memory regions are identical, false if they differ
+ */
+__rte_experimental
+static inline bool
+rte_memeq_consttime(const void *a, const void *b, size_t n)
+{
+	return !rte_memneq_consttime(a, b, n);
+}
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.34.1

[dpdk-dev v4 2/2] crypto/ipsec-mb: use constant-time memory comparison

[Kai Ji]

Replace memcmp() with rte_memneq_consttime() in cryptographic
authentication verification operations across iipsec-mb drivers.

Note: OpenSSL crypto driver already uses CRYPTO_memcmp() which
provides equivalent timing attack resistance and is left unchanged.

Note: scheduler driver memcmp stays unchanged as its not secret data
comparison and actually faster with no timing attack risk.

Bugzilla ID: 1773
Cc: stable@dpdk.org

[0] https://bugs.dpdk.org/show_bug.cgi?id=1773

Signed-off-by: Kai Ji <kai.ji@intel.com>
---
 drivers/crypto/ipsec_mb/pmd_aesni_gcm.c | 5 ++---
 drivers/crypto/ipsec_mb/pmd_aesni_mb.c  | 6 +++---
 drivers/crypto/ipsec_mb/pmd_snow3g.c    | 4 ++--
 drivers/crypto/ipsec_mb/pmd_zuc.c       | 4 ++--
 4 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c b/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c
index 8d40bd9169..a3d1d19025 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_gcm.c
@@ -206,7 +206,7 @@ post_process_gcm_crypto_op(struct ipsec_mb_qp *qp,
 				tag, session->req_digest_length);
 #endif
 
-		if (memcmp(tag, digest,	session->req_digest_length) != 0)
+		if (rte_memneq_consttime(tag, digest, session->req_digest_length))
 			op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
 	} else {
 		if (session->req_digest_length != session->gen_digest_length) {
@@ -558,8 +558,7 @@ aesni_gcm_sgl_op_finalize_decryption(const struct aesni_gcm_session *s,
 	ops.finalize_dec(&s->gdata_key, gdata_ctx, tmpdigest,
 			s->gen_digest_length);
 
-	return memcmp(digest, tmpdigest, s->req_digest_length) == 0 ? 0
-								    : EBADMSG;
+	return rte_memneq_consttime(digest, tmpdigest, s->req_digest_length) ? EBADMSG : 0;
 }
 
 static inline void
diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
index a6c3f09b6f..f0f67faa46 100644
--- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
+++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c
@@ -1902,7 +1902,7 @@ verify_docsis_sec_crc(IMB_JOB *job, uint8_t *status)
 	crc = job->dst + crc_offset;
 
 	/* Verify CRC (at the end of the message) */
-	if (memcmp(job->auth_tag_output, crc, RTE_ETHER_CRC_LEN) != 0)
+	if (rte_memneq_consttime(job->auth_tag_output, crc, RTE_ETHER_CRC_LEN))
 		*status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
 }
 
@@ -1910,7 +1910,7 @@ static inline void
 verify_digest(IMB_JOB *job, void *digest, uint16_t len, uint8_t *status)
 {
 	/* Verify digest if required */
-	if (memcmp(job->auth_tag_output, digest, len) != 0)
+	if (rte_memneq_consttime(job->auth_tag_output, digest, len))
 		*status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
 }
 
@@ -2305,7 +2305,7 @@ verify_sync_dgst(struct rte_crypto_sym_vec *vec,
 
 	for (i = 0, k = 0; i != vec->num; i++) {
 		if (vec->status[i] == 0) {
-			if (memcmp(vec->digest[i].va, dgst[i], len) != 0)
+			if (rte_memneq_consttime(vec->digest[i].va, dgst[i], len))
 				vec->status[i] = EBADMSG;
 			else
 				k++;
diff --git a/drivers/crypto/ipsec_mb/pmd_snow3g.c b/drivers/crypto/ipsec_mb/pmd_snow3g.c
index 65f0e5c568..5d99ea568f 100644
--- a/drivers/crypto/ipsec_mb/pmd_snow3g.c
+++ b/drivers/crypto/ipsec_mb/pmd_snow3g.c
@@ -269,8 +269,8 @@ process_snow3g_hash_op(struct ipsec_mb_qp *qp, struct rte_crypto_op **ops,
 					&session->pKeySched_hash,
 					iv, src, length_in_bits, dst);
 			/* Verify digest. */
-			if (memcmp(dst, ops[i]->sym->auth.digest.data,
-					SNOW3G_DIGEST_LENGTH) != 0)
+			if (rte_memneq_consttime(dst, ops[i]->sym->auth.digest.data,
+					SNOW3G_DIGEST_LENGTH))
 				ops[i]->status =
 					RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
 		} else {
diff --git a/drivers/crypto/ipsec_mb/pmd_zuc.c b/drivers/crypto/ipsec_mb/pmd_zuc.c
index 44781be1d1..466f6594e5 100644
--- a/drivers/crypto/ipsec_mb/pmd_zuc.c
+++ b/drivers/crypto/ipsec_mb/pmd_zuc.c
@@ -185,8 +185,8 @@ process_zuc_hash_op(struct ipsec_mb_qp *qp, struct rte_crypto_op **ops,
 	 */
 	for (i = 0; i < processed_ops; i++)
 		if (sessions[i]->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY)
-			if (memcmp(dst[i], ops[i]->sym->auth.digest.data,
-					ZUC_DIGEST_LENGTH) != 0)
+			if (rte_memneq_consttime(dst[i], ops[i]->sym->auth.digest.data,
+					ZUC_DIGEST_LENGTH))
 				ops[i]->status =
 					RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
 
-- 
2.34.1

Re: [dpdk-dev v4 1/2] eal: Add mem equal and non-equal to prevent timing attacks memcmp.

[Stephen Hemminger]

On Mon, 29 Sep 2025 14:50:48 +0000
Kai Ji <kai.ji@intel.com> wrote:

> diff --git a/lib/eal/include/rte_memory.h b/lib/eal/include/rte_memory.h
> index dcc0e69cfe..bbdef8e939 100644
> --- a/lib/eal/include/rte_memory.h
> +++ b/lib/eal/include/rte_memory.h
> @@ -746,6 +746,74 @@ __rte_experimental
>  void
>  rte_memzero_explicit(void *dst, size_t sz);
>  
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Constant-time memory inequality comparison.
> + *
> + * This function compares two memory regions in constant time, making it
> + * resistant to timing side-channel attacks. The execution time depends only
> + * on the length parameter, not on the actual data values being compared.
> + *
> + * This is particularly important for cryptographic operations where timing
> + * differences could leak information about secret keys, passwords, or other
> + * sensitive data.
> + *
> + * @param a
> + *   Pointer to the first memory region to compare
> + * @param b
> + *   Pointer to the second memory region to compare
> + * @param n
> + *   Number of bytes to compare
> + * @return
> + *   false if the memory regions are identical, true if they differ
> + */
> +__rte_experimental
> +static inline bool
> +rte_memneq_consttime(const void *a, const void *b, size_t n)

NAK
Please change to match BSD equivalent function (ie not not equal)

RE: [dpdk-dev v4 1/2] eal: Add mem equal and non-equal to prevent timing attacks memcmp.

[Morten Brørup]

> From: Kai Ji [mailto:kai.ji@intel.com]
> Sent: Monday, 29 September 2025 16.51
> 
> Bugzilla ID: 1773
> Cc: stable@dpdk.org
> 
> [0] https://bugs.dpdk.org/show_bug.cgi?id=1773
> 
> Signed-off-by: Kai Ji <kai.ji@intel.com>
> ---

Acked-by: Morten Brørup <mb@smartsharesystems.com>

@Stephen: V4 also includes equal, which you was asking for.

Re: [dpdk-dev v4 1/2] eal: Add mem equal and non-equal to prevent timing attacks memcmp.

[Stephen Hemminger]

On Mon, 29 Sep 2025 19:48:19 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > From: Kai Ji [mailto:kai.ji@intel.com]
> > Sent: Monday, 29 September 2025 16.51
> > 
> > Bugzilla ID: 1773
> > Cc: stable@dpdk.org
> > 
> > [0] https://bugs.dpdk.org/show_bug.cgi?id=1773
> > 
> > Signed-off-by: Kai Ji <kai.ji@intel.com>
> > ---  
> 
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> 
> @Stephen: V4 also includes equal, which you was asking for.
> 

The point is that we should only have the eq variant.
Having the not equal is unnecessary addition.

Re: [dpdk-dev v4 2/2] crypto/ipsec-mb: use constant-time memory comparison

[Stephen Hemminger]

On Mon, 29 Sep 2025 14:50:49 +0000
Kai Ji <kai.ji@intel.com> wrote:

> Replace memcmp() with rte_memneq_consttime() in cryptographic
> authentication verification operations across iipsec-mb drivers.
> 
> Note: OpenSSL crypto driver already uses CRYPTO_memcmp() which
> provides equivalent timing attack resistance and is left unchanged.
> 
> Note: scheduler driver memcmp stays unchanged as its not secret data
> comparison and actually faster with no timing attack risk.
> 
> Bugzilla ID: 1773
> Cc: stable@dpdk.org
> 
> [0] https://bugs.dpdk.org/show_bug.cgi?id=1773
> 
> Signed-off-by: Kai Ji <kai.ji@intel.com>
> ---

Thanks for doing this.
A couple other notes from my searching around.
The function memeq_consttime is in NetBSD (not FreeBSD) sorry if I got confused.
OpenBSD has timingsafe_memcmp() and timingsafe_bcmp().

Also this on LWN:

> You would use a constant-time version of memcmp. OpenBSD added timingsafe_bcmp in 2009, and then timingsafe_memcmp a few years later. (https://man.openbsd.org/timingsafe_memcmp.3) NetBSD has consttime_memequal. (https://man.netbsd.org/consttime_memequal.3) Apple and FreeBSD adopted the OpenBSD routines.
> I don't think either glibc or musl libc have adopted a similar interface. So on Linux or for portable software you'd probably want to use CRYPTO_memcmp from OpenSSL.
> 
> You should of course be hashing the passwords with salts, and only comparing those hashes. In which case using a constant-time compare isn't that important as the attacker can't work backward from the short-circuiting compare to decipher the plaintext input. The hashing itself should be constant-time, assuming modern digests like SHA-256 or SHA-3, though it's possible the *length* of the input password would leak. But there are a gazillion ways for the length to leak, and when it comes to password-based authentication schemes that's the least of your worries.
> 
> 
> 

RE: [dpdk-dev v4 1/2] eal: Add mem equal and non-equal to prevent timing attacks memcmp.

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 30 September 2025 00.49
> 
> On Mon, 29 Sep 2025 19:48:19 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > > From: Kai Ji [mailto:kai.ji@intel.com]
> > > Sent: Monday, 29 September 2025 16.51
> > >
> > > Bugzilla ID: 1773
> > > Cc: stable@dpdk.org
> > >
> > > [0] https://bugs.dpdk.org/show_bug.cgi?id=1773
> > >
> > > Signed-off-by: Kai Ji <kai.ji@intel.com>
> > > ---
> >
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >
> > @Stephen: V4 also includes equal, which you was asking for.
> >
> 
> The point is that we should only have the eq variant.
> Having the not equal is unnecessary addition.

Yes, I would tend to agree with Stephen on this.