DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Kai Ji <kai.ji@intel.com>
Cc: dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v3] examples: add Wycheproof validation app
Date: Mon, 21 Sep 2026 09:41:20 -0700	[thread overview]
Message-ID: <20260921094120.53bea0af@phoenix.local> (raw)
In-Reply-To: <20260917153420.2609071-1-kai.ji@intel.com>

On Thu, 17 Sep 2026 15:34:19 +0000
Kai Ji <kai.ji@intel.com> wrote:

> Add a Wycheproof JSON vector validation example for cryptodev PMDs.
> 
> Support these algorithms when advertised by the selected PMD:
> - AEAD: AES-GCM, AES-CCM, SM4-GCM, ChaCha20-Poly1305
> - MAC: AES-CMAC, AES-GMAC, HMAC SHA-1/SHA-2/SHA-3/SM3
> - Asymmetric: DSA (P1363 verify), ECDSA (P1363 verify),
>   ECDH (ecpoint shared-secret compute)
> 
> Validate valid vectors against generated ciphertexts, tags, plaintexts,
> digests, shared secrets, or signature verification, and require the
> expected rejection for invalid vectors. Digest inputs for DSA and ECDSA
> use the symmetric auth path, selecting a separate symmetric-capable
> device when the target device is asymmetric-only.
> 
> Skip parameter combinations outside PMD capability ranges and identify
> recognized vector families without a compatible DPDK transform. A
> --debug option lists every failed or skipped vector.
> 
> Add Meson and standalone build integration, with usage documentation.
> 
> Signed-off-by: Kai Ji <kai.ji@intel.com>
> ---

Wycheproof validation example (v3) - review

Applied on 6bbb7b3, built with -Dwerror=true, ran against
crypto_openssl on 12 Wycheproof v1 files (GCM, CCM, ChaCha20-Poly1305,
HMAC-SHA1/256, CMAC, GMAC, DSA, ECDSA, ECDH). No validation failures
on supported vectors.

Errors
------

doc/guides/sample_app_ug/wycheproof_validation.rst:5
  Title underline is 28 characters under a 29-character title:
    Wycheproof Validation Example
    ============================
  docutils reports "Title underline too short"; doc/guides/meson.build
  adds -W under -Dwerror, so the doc build fails. Add one '='.

Warnings
--------

main.c:790-792 validate_aead_vector()
    vector->msg_len > env.mbuf_data_room
  Usable room in a fresh mbuf is data_room - RTE_PKTMBUF_HEADROOM.
  A message inside that 128-byte window passes this check, run_aead()
  returns -EMSGSIZE at line 536, and line 806 (ret != 0) counts it as
  a validation failure, so the exit status is nonzero. Verified:
  --mbuf-dataroom 160 on aes_gcm_test.json gives failed=54, all
  ret=-90. run_hmac(), run_gmac() and compute_hash() have no
  pre-check at all and misclassify the same way (--mbuf-dataroom 128
  on hmac_sha256_test.json: failed=110). Compare against
  env.mbuf_data_room - RTE_PKTMBUF_HEADROOM and map -EMSGSIZE to
  skipped_unsupported in every caller.

main.c:148-151 parse_args()
    if (parse_uint32(optarg, &value) != 0 ||
            !rte_cryptodev_is_valid_dev(value))
    env.dev_id = value;
  rte_cryptodev_is_valid_dev() takes uint8_t; value is truncated
  before the validity check and again on assignment. Verified:
  --cryptodev-id 256 silently runs on device 0 while --cryptodev-id 1
  is correctly rejected. Reject value > UINT8_MAX (or
  >= RTE_CRYPTO_MAX_DEVS) before the call.

main.c:577-580 run_aead(), and the same pattern at 751, 1108, 1190,
1440, 1667
    completed = dequeue_one(env.dev_id);
    if (completed == NULL) {
        ret = -ETIMEDOUT;
        goto out;
    }
  On timeout the op, mbuf, digest/aad buffers and session are freed
  at out: while the enqueued op is still owned by the PMD, then the
  tool moves on to the next vector. A hardware PMD (QAT is named as
  the target) completes into freed memory, and the next dequeue_one()
  can hand back the stale op as the current vector's result. Treat
  -ETIMEDOUT as fatal: propagate it to main() and stop, rather than
  free and continue.

Info
----

main.c:807-808, 817, 918, 998
    memcmp(output, vector->ct, vector->ct_len) != 0
  When msg_len/ct_len is 0, run_aead() leaves *output NULL and
  decode_hex() leaves the vector buffer NULL, so this is
  memcmp(NULL, NULL, 0). Wycheproof has many empty-message vectors.
  glibc declares memcmp nonnull; -fsanitize=nonnull-attribute trips
  on it. Guard with len != 0 &&.

MAINTAINERS:2038
  "Other Example Applications" is alphabetical; the new entry sits
  between FIPS and Flow filtering. Move it after "VMDq examples".

main.c:180
    struct rte_cryptodev_config config = { rte_socket_id(), 1, 0 };
  Positional initializer; use .socket_id/.nb_queue_pairs/.ff_disable.

doc/guides/sample_app_ug/wycheproof_validation.rst
  The documented crypto_openssl PMD advertises no ECDSA or ECDH xform
  capability (rte_openssl_pmd_ops.c capability table), so with the
  documented command line every ECDSA/ECDH vector lands in
  skipped_capability (verified: 0 passed, 241 skipped on
  ecdsa_secp256r1_sha256_p1363_test.json). Worth a sentence that
  asymmetric coverage needs a PMD advertising those xforms.

Review-Result: ERROR

  parent reply	other threads:[~2026-09-21 16:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 15:51 [PATCH] examples: add Wycheproof validation app Kai Ji
2026-09-15 16:58 ` Stephen Hemminger
2026-09-15 18:28 ` Stephen Hemminger
2026-09-17 15:34 ` [PATCH v3] " Kai Ji
2026-09-21 12:05   ` [EXTERNAL] " Gowrishankar Muthukrishnan
2026-09-21 16:41   ` Stephen Hemminger [this message]
2026-09-22 14:47   ` [PATCH v4] " Kai Ji
2026-09-22 16:05     ` [PATCH v5] " Kai Ji
2026-09-22 16:26       ` Stephen Hemminger
2026-09-23 10:50       ` [PATCH v6] " Kai Ji
2026-09-23 15:04         ` [PATCH v7] " Kai Ji
2026-09-24 14:35           ` [EXTERNAL] " Akhil Goyal
2026-09-24 15:01             ` Ji, Kai
2026-09-24 18:00               ` Akhil Goyal
2026-09-25 16:32                 ` Thomas Monjalon
2026-09-29 16:12                   ` Ji, Kai
2026-09-29 18:21                     ` Akhil Goyal

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=20260921094120.53bea0af@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=kai.ji@intel.com \
    --cc=thomas@monjalon.net \
    /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