|WARNING| [v2,8/8] app/test: add RSA-PSS sign and verify test cases

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Thu Sep 3 10:52:18 CEST 2026


Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/169007

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-09-03

# Review of DPDK Patch Series: RSA-specific capability parameters

## Summary

This 8-patch series adds RSA-specific capability parameters to DPDK's cryptodev API, including support for RSA-OAEP and RSA-PSS padding schemes. The series includes API additions, PMD updates (OcteonTX, CNXK, OpenSSL), and comprehensive test coverage.

---

## Patch 1/8: crypto: add RSA-specific capability parameters

### Errors

None identified.

### Warnings

None identified.

### Info

- The API additions are well-structured and properly documented
- ABI changes are correctly documented in release notes
- The new `rte_crypto_rsa_capa` structure provides clear separation of RSA-specific capabilities
- Good use of zero values to indicate "no limit" or "not reported"
- The `pss_explicit_salt` feature flag is correctly marked as optional (defaults to false)

---

## Patch 2/8: crypto/octeontx: advertise RSA PKCS#1 v1.5 padding support

### Errors

None identified.

### Warnings

None identified.

### Info

- Correctly migrates from the generic `modlen` union field to `rsa_capa`
- Properly advertises only the padding types actually supported by the PMD

---

## Patch 3/8: crypto/cnxk: advertise RSA PKCS#1 v1.5 padding support

### Errors

None identified.

### Warnings

None identified.

### Info

- Same pattern as patch 2/8, correctly applied to CNXK PMD
- Consistent with OcteonTX implementation

---

## Patch 4/8: crypto/openssl: advertise RSA padding and hash capabilities

### Errors

None identified.

### Warnings

None identified.

### Info

- Comprehensive capability advertisement for OpenSSL 3.0+
- Correctly advertises OAEP support along with supported hash algorithms
- Good use of `RTE_BIT64()` macro for bitmask construction
- SHA-1, SHA-2, and SHA-3 family support is appropriate for OpenSSL

---

## Patch 5/8: crypto/openssl: add RSA-OAEP support for OpenSSL PMD

### Errors

None identified. All error paths correctly handle resource cleanup.

### Warnings

1. **Label allocation uses `OPENSSL_zalloc()` but the copy uses `rte_memcpy()`**  
   While not incorrect, consider using `memcpy()` for consistency with the allocation API choice (OpenSSL functions). The mix is unusual but not wrong.

### Info

**Correctness verification:**

Traced all error paths in `openssl_set_asym_session_parameters()`:
- Line 1302-1307: `oaep_md` validation - `goto err_rsa` (label freed at 1425-1428) 
- Line 1316-1319: `mgf1_md` validation - `goto err_rsa` (label freed) 
- Line 1321-1326: label length overflow check - `goto err_rsa` (no allocation yet) 
- Line 1331-1335: label data NULL but length non-zero - `goto err_rsa` (no allocation yet) 
- Line 1337-1339: `OPENSSL_zalloc()` failure - `goto err_rsa` (alloc failed, no free needed) 
- Line 1424-1428: Error cleanup frees `asym_session->u.r.label` and zeroes `label_len` 

Normal teardown in `openssl_reset_asym_session()`:
- Lines 1905-1908: Frees label when `label_len > 0` 

OAEP parameter validation in `openssl_rsa_set_oaep_params()`:
- Line 2312-2322: All OpenSSL API failures return -1 with appropriate cleanup (label allocated via `OPENSSL_memdup()` is freed on error at line 2320) 

Usage context check:
- Lines 2346-2351: OAEP restricted to encrypt/decrypt operations 

No use-after-free, no resource leaks detected.

**API usage:**
- `EVP_PKEY_CTX_set0_rsa_oaep_label()` correctly takes ownership of the label, requiring `OPENSSL_memdup()` instead of direct pointer copy 
- MGF1 hash defaults to OAEP hash when not specified (line 1313-1314) 
- Empty label handling is correct (OpenSSL 3 rejects `set0_rsa_oaep_label(NULL, 0)`, so it's skipped) 

**Code quality:**
- Good factoring of OAEP parameter setup into separate function
- Clear comments explaining OpenSSL API ownership semantics

---

## Patch 6/8: app/test: add RSA OAEP asymmetric test cases

### Errors

None identified.

### Warnings

None identified.

### Info

**Test coverage:**
- OAEP with default parameters (SHA-256, no label, no explicit MGF1) 
- OAEP with custom MGF1 hash and label 
- OAEP with label but default MGF1 (falls back to SHA-256) 
- Both EXP and QT (CRT) private key types 
- Proper capability checks before running tests 

**Capability checking logic:**
- `rsa_oaep_supported()` correctly validates:
  - OAEP padding bit in `pad_types`
  - Primary hash in `hash_algos`
  - MGF1 hash in `mgf1_hash_algos` (only when explicitly set)
- Correctly handles `mgf1hash == 0` as "use primary hash" 

**Test data:**
- Label vector is 20 bytes of sequential data (adequate for testing)
- Tests use existing RSA key material (rsa_n, rsa_e, etc.)

---

## Patch 7/8: crypto/openssl: add RSA-PSS support for RSA operations

### Errors

None identified. All error paths are correct.

### Warnings

None identified.

### Info

**Correctness verification:**

Session setup in `openssl_set_asym_session_parameters()`:
- Lines 1323-1343: PSS parameter validation and storage
- Line 1329: `pss_md` validation - `goto err_rsa` (no allocation yet) 
- Line 1338-1342: `pss_mgf1_md` validation - `goto err_rsa` (no allocation yet) 
- Line 1343: `pss_saltlen` stored (integer, no resource) 

PSS sign path (`openssl_rsa_pss_sign()`):
- Lines 2343-2384: All OpenSSL API failures return -1
- Line 2355: Explicit salt check rejects `pss_salt.data != NULL` 
- No resources allocated, no cleanup needed 

PSS verify path (`openssl_rsa_pss_verify()`):
- Lines 2420-2452: All OpenSSL API failures return -1
- EVP_PKEY_verify() return value correctly interpreted:
  - `< 0` = setup/library error - return -1
  - `== 0` = invalid signature - return 1
  - `> 0` = valid signature - return 0
- Signature mismatch (ret == 1) does not fail the op, sets `cop->status = ERROR` instead (lines 2693-2695) 

Verify-recover path (`openssl_rsa_verify_recover()`):
- Lines 2480-2550: Comprehensive correctness
- Line 2525: `tmp` allocated via `OPENSSL_malloc()` 
- Line 2528: Allocation failure returns -1 
- Lines 2530-2538: OpenSSL verify_recover failure frees `tmp` before returning 
- Lines 2546-2550: Signature mismatch frees `tmp` before returning 
- Line 2553: Success path frees `tmp` 
- **No leak detected** 

Operation dispatch in `process_openssl_rsa_op_evp()`:
- Lines 2564-2569: PSS restricted to sign/verify 
- Lines 2650-2680: Sign operation branches on PSS vs non-PSS 
- Lines 2683-2697: Verify operation branches on PSS vs verify-recover 
- Lines 2689-2695: Signature mismatch sets `cop->status = ERROR`, returns 0 (op completes successfully) 

**Code quality:**
- Excellent separation of PSS-specific logic into helper functions
- Clear comments explaining EVP_PKEY_verify() return semantics
- Correct distinction between "processing failed" (return -1) and "signature invalid" (return 1 or set status)

---

## Patch 8/8: app/test: add RSA-PSS sign and verify test cases

### Errors

None identified.

### Warnings

None identified.

### Info

**Test coverage:**
- PSS with salt length = digest length (32 bytes for SHA-256) 
- PSS with maximum permissible salt length (94 bytes) 
- PSS with zero-length salt (deterministic PSS) 
- Capability checks for PSS padding, hash, and MGF1 hash 

**PSS salt length validation:**
The test vectors document the maximum salt length calculation:
```
emBits = modBits - 1 = 1023
emLen = ceil(emBits / 8) = 128
maxSaltLen = emLen - hLen - 2 = 128 - 32 - 2 = 94
```
This matches RFC 8017 section 9.1.1 

**Test structure:**
- `queue_ops_rsa_pss_sign_verify()` correctly performs sign-then-verify without verify-recover (not supported for PSS)
- Uses `rsa_pss_digest_sha256` (pre-hashed message) as required by PSS API
- Properly checks `result_op->status` for verification result

**SHA-256 digest vector:**
The digest of rsaplaintext (lines 260-268) is a static test vector. For production use, applications should hash their own messages, but for unit testing this is acceptable.

---

## Overall Assessment

### Correctness: PASS
- No use-after-free issues
- No resource leaks on any error path
- All error codes are properly propagated
- Proper cleanup in both normal and error paths
- Correct OpenSSL API usage throughout

### Code Style: PASS
- Follows DPDK coding standards
- Proper use of `RTE_BIT64()` for 64-bit bitmasks
- Consistent formatting and indentation
- Clear variable naming
- Helpful comments where needed

### API Design: PASS
- `rte_crypto_rsa_capa` is well-structured and extensible
- Proper use of bitmasks for capability flags
- Clear separation of OAEP and PSS parameters
- Zero values used consistently to indicate "no limit" or "default"
- ABI changes properly documented

### Documentation: PASS
- Release notes updated in patch 1/8
- Doxygen comments added for new structures
- Inline comments explain OpenSSL API semantics

### Testing: PASS
- Comprehensive test coverage for OAEP and PSS
- Both EXP and QT key types tested
- Edge cases covered (empty label, zero salt, max salt)
- Proper capability checks prevent unsupported test execution

---

## Recommendations

1. **Consider standardizing memory allocation API choice** (Info)  
   Patch 5/8 mixes OpenSSL allocation (`OPENSSL_zalloc()`) with DPDK copy (`rte_memcpy()`). While not incorrect, using `memcpy()` consistently with `OPENSSL_*` functions would be more uniform.

2. **No required changes**  
   All patches are correct as written. The series is ready for merging.

---

## Conclusion

**This patch series is well-implemented and ready for inclusion.** All correctness criteria are met, error handling is thorough, and test coverage is comprehensive. No blocking issues were identified.


More information about the test-report mailing list