[test] add fuzz targets for sequences of tbor commands and dispatcher

[David Zimmermann (zimmy87)]

No description provided.

[Copilot]

🟡 Changes recommended

The new targets can silently select and repeatedly factory-reset a persistent hardware device.

4 open findings

• Prevent implicit hardware selection and destructive factory resets · New
• Prevent implicit hardware selection and destructive factory resets · New
• Prevent implicit hardware selection and destructive factory resets · New
• Prevent implicit hardware selection and destructive factory resets · New

What changed in this PR

Adds four TBOR fuzz targets covering command sequences, ECC dispatch, AES fast paths, and session operations.

Changes:

• Adds and registers four fuzz binaries.
• Exercises valid and malformed TBOR requests.
• Reformats existing policy-key construction.

File	Description
fuzz/​Cargo.toml	Registers the new fuzz targets.
fuzz/​fuzz_targets/​common.rs	Formatting-only change.
fuzz_tbor_cmd_reqs.rs	Fuzzes command sequences.
fuzz_tbor_dispatcher.rs	Fuzzes ECC request dispatch.
fuzz_tbor_dispatcher_aes_fp.rs	Fuzzes AES fast-path inputs.
fuzz_tbor_app_ops.rs	Fuzzes session operations.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Some driver failures are suppressed, and MAC mutation can produce false fuzz crashes.

3 open findings

• MAC mutation can cancel itself and submit an unchanged valid MAC · New
• AES sequence suppresses driver errors for invalid sessions · New
• Invalid-request oracle incorrectly accepts driver errors · New

4 resolved since last review

• Prevent implicit hardware selection and destructive factory resets
• Prevent implicit hardware selection and destructive factory resets
• Prevent implicit hardware selection and destructive factory resets
• Prevent implicit hardware selection and destructive factory resets

🧠 Review effort: Balanced

[Copilot]

🔵 Needs a closer look

The command-sequence target incorrectly accepts ECC and HMAC driver failures as expected invalid-session rejections.

0 open findings

3 resolved since last review

• Invalid-request oracle incorrectly accepts driver errors
• AES sequence suppresses driver errors for invalid sessions
• MAC mutation can cancel itself and submit an unchanged valid MAC

🧠 Review effort: Balanced

[Copilot]

🔵 Needs a closer look

The app-operations target cannot reach its main paths, and two command branches suppress driver failures.

0 open findings

Previously missed (1)

In code that hasn't changed since last review

Secondary CO sessions blocked by exhausted bootstrap session slots

fuzz/​fuzz_targets/​ddi/​tbor/​fuzz_tbor_app_ops.rs:61

The bootstrap session is an active Crypto-Officer session, and CO handshakes have only slot 0 available. Consequently every secondary CO SessionOpenInit reaches VaultSessionLimitReached here and immediately continues, so no finish-MAC or close operation below is ever exercised. Use the rotated CU fixture/credentials for the primary and secondary handles (CU has slots 1–7), or close the bootstrap CO and restructure the per-handle-limit check before opening secondaries.

🧠 Review effort: Balanced