gistfile1.txt

The numbers tell a clear, compelling story. Here is a breakdown of what the empirical data proves and a couple of subtle technical details to call out in your final report.

---

### Key Takeaways & Architecture Validation

#### 1. TrustZone Overhead & Data Plane Allocation

* **Overhead Math:** $\approx 0.57\text{ ms}$ per IPC call.
* At $1,036\text{ pkt/s}$ (your NSPE ChaCha20 speed), processing $1,036\text{ packets}$ takes about $0.965\text{ ms}$ per packet total.
* **Impact:** If you routed each packet into SPE via TF-M, the $0.57\text{ ms}$ IPC overhead would add **$\sim 59\%$ latency per packet**, capping your theoretical max throughput to under $600\text{ pkt/s}$ ($\sim 6.9\text{ Mbit/s}$) purely due to context switching and cross-boundary marshaling.
* **Verdict:** Placing the WireGuard data plane in NSPE is completely validated.

#### 2. RNG Performance: The Real Shocker

* **NSPE:** 128,000 ops/s vs. **SPE:** 1,742 ops/s (a ~73× drop).
* This huge delta isn't hardware TRNG limitation; it's almost entirely **NSPE $\rightarrow$ SPE PSA call IPC overhead** combined with TF-M thread scheduling for tiny 64-byte requests.
* **Design Rule:** Re-seeding a local CSPRNG in NSPE from the TF-M TRNG periodically (or during initial handshakes) makes sense, but making direct PSA entropy calls per-packet would be disastrous for performance.

#### 3. Control Plane Rationale (ECDH & Sign)

* **X25519:** $254\text{ ms}$ (NSPE) $\rightarrow$ $111\text{ ms}$ (SPE) (**2.3× faster**)
* **ECDSA P-256:** $554\text{ ms}$ (NSPE) $\rightarrow$ $132\text{ ms}$ (SPE) (**4.2× faster**)
* **Why this happens:** In NSPE, mbedTLS is doing generic, unoptimized C software math (bignum/ECP routines). In SPE, TF-M links against NXP's driver (`p256-m` / ELS PKHA hardware wrappers), which offloads or heavily optimizes modular exponentiation.
* **Control Plane Split Strategy:**
* WireGuard Handshakes ($1$ X25519 per exchange, every few minutes) take $\sim 100\text{ ms}$ in SPE. Pay the $0.57\text{ ms}$ IPC tax once to get the accelerated hardware/optimized execution and isolated private key storage.
* WireGuard Data Plane ($1,000+$ packets/sec) stays in NSPE to avoid paying $0.57\text{ ms}$ tax thousands of times per second.



---

### Low-Hanging Fruit for the Follow-Up Phase

Your observed $12.0\text{ Mbit/s}$ ceiling for ChaCha20-Poly1305 on a $150\text{ MHz}$ Cortex-M33 is typical for stock, scalar C implementations in mbedTLS. If you need to squeeze more throughput out of NSPE without hardware acceleration, consider:

1. **Compiler Flags & SIMD/DSP Extensions:** Ensure GCC/Clang has `-mcpu=cortex-m33` with DSP extensions enabled (`+dsp`). Stock mbedTLS ChaCha20 often defaults to pure scalar 32-bit math unless explicitly told to use Arm SIMD/DSP assembly primitives.
2. **Dedicated Assembly Kernels:** Dropping in an optimized Armv8-M mainline hand-rolled assembly inner-loop for ChaCha20 (such as from *SUPERCOP* or *monocypher*) typically doubles ChaCha20-Poly1305 throughput on Cortex-M33 to around $25\text{--}30\text{ Mbit/s}$.

---

### Summary Table for Documentation / Benchmarking Report

| Workload | Recommended Domain | Rationale / Driver |
| --- | --- | --- |
| **Data Plane (AEAD / ChaCha20)** | **NSPE** | Avoids $0.57\text{ ms}$ IPC penalty per packet; maxes out CPU pipelining. |
| **Control Plane (X25519 / Auth)** | **SPE (TF-M)** | Hardware/driver-accelerated math ($2\text{--}4\times$ faster execution); isolates session keys. |
| **Entropy / RNG** | **Hybrid** | Fetch seeds from SPE via TRNG; expand in NSPE via lightweight CSPRNG. |

This gives you a rock-solid, data-backed architecture argument for the CampfireOS technical whitepaper.