Facing Extinction: The Fight To Keep Hardware Crypto Engines in Em... Kamlesh Gurudasani & T Pratham

### Overview In this talk, Pratham and Kamlesh from Texas Instruments (TI) discuss the growing tension between upstream Linux kernel maintainers and embedded hardware vendors regarding dedicated hardware cryptographic engines. Upstream maintainers have increasingly blocked new hardware crypto drivers and purged existing support—such as in dm-crypt, fscrypt, and AF_ALG—arguing that hardware accelerators offer inferior performance compared to modern CPU software implementations and create undue maintenance burdens. The speakers argue that while these hardware engines may perform poorly in server-style throughput benchmarks on high-frequency application cores, they remain critical for embedded threat models, secure boot, power efficiency, hardware key isolation, and physical side-channel defenses.

### Key Topics - **Upstream Rejections and Deprecations**: Maintainers (such as Eric Biggers) are removing kernel support for crypto accelerators and rejecting incoming drivers from vendors like TI, NXP, Qualcomm, and STMicroelectronics. - **The Performance Disparity**: On application cores (e.g., ARM Cortex-A53 or server CPUs), software utilizing vector or crypto instructions (ARMv8 Crypto Extensions, x86 AVX-512) is often 12x to 56x faster than hardware accelerators due to high core clock frequencies and DMA overhead. - **Embedded vs. Server Threat Modeling**: Server maintainers prioritize raw throughput, whereas embedded systems (smart meters, medical devices, automotive ECUs) require physical side-channel attack mitigations (DPA, EMA), hardware key storage, and regulatory certification compliance. - **Upstream Maintenance Failures**: Vendors often treat upstreaming as a one-time handoff, failing to actively maintain drivers, resolve reported bugs, provide public documentation, or run continuous integration testing (KernelCI).

### Technical Details - **Architecture Comparison**: Cryptographic accelerators are dedicated silicon RTL blocks connected via internal buses with their own clocks, power domains, and DMA engines (e.g., TI SA2UL and DTHEv2, NXP CAAM, Qualcomm QCE, Intel QAT). In contrast, CPU instructions like ARMv8-CE or x86 VAES execute directly on the application core, sharing its power domain, cache, and address space without hardware isolation. - **Throughput Metrics**: In LKML benchmarks cited, Intel Emerald Rapids AVX-512 reached ~16,000 Mbps for AES compared to ~285–289 Mbps on Intel QAT (~56x slower). On TI's AM62L, ARMv8 AES-XTS software achieved ~700 Mbps versus 50–55 Mbps on DTHEv2 (~12x slower). Even on Cortex-A7 lacking crypto extensions, software outperformed hardware accelerators by 4x. - **The True Role of Accelerators**: The speakers highlight that these engines were originally designed to accelerate low-frequency cores (e.g., Cortex-M4 running at ~400 MHz for secure boot), where offloading to an accelerator improves throughput from ~50 Mbps to 100+ Mbps, significantly speeding up boot time. - **Side-Channel and Physical Attacks**: Running cryptography in CPU software exposes systems to Differential Power Analysis (DPA), Electromagnetic Analysis (EMA), cache analysis, and cold-boot memory attacks. In unattended field devices, attacks can be executed using toolkits under $500. Hardware crypto engines counter these by implementing RTL-level DPA/EMA countermeasures and ensuring cryptographic keys never enter system RAM. - **Compliance and Certifications**: Level 3 security certifications (including FIPS, IEC, ISO 21434, and PSA Certified) mandate hardware-level protections against DPA/EMA, which ARM CPU instructions cannot satisfy without dedicated hardware countermeasures.

### Takeaways - Upstream kernel maintainers are justified in purging drivers when vendors abandon maintenance, fail to implement promised features (like hardware key stores), or ignore reported bugs. - Hardware crypto engines are not primarily throughput accelerators for Linux application cores; their real value lies in physical attack mitigation, hardware key isolation, and certification compliance. - To halt this "extinction," silicon vendors must change their upstream practices: they must articulate explicit embedded use cases, actively maintain drivers across kernel releases, publish hardware documentation, integrate hardware with automated kernel testing (KernelCI), and clearly communicate embedded threat models to upstream maintainers.