FPGA-Assisted Side-Channel Mitigation: A Lavalamp Research Note

The short version

A CPU timing side channel can let an adversary infer secret-dependent behavior from repeated timing observations. Exploitability depends on the victim implementation, measurement access, noise, scheduling or co-residency, and the specific microarchitectural channel. Constant-time cryptography is the primary defense against secret-dependent control flow and memory access.

Side-channel attacks on modern CPUs remain an active research area. AMD's August 2026 security bulletin AMD-SB-7069 describes a scheduler-contention side channel across AMD Zen processors as a variant of known techniques, not a new vulnerability, and recommends constant-time algorithms and avoiding secret-dependent control flow. Any claim that this bulletin validates Lavalamp's disclosure needs a matching case identifier and an explicit AMD acknowledgement.

Lavalamp explores an FPGA-assisted layer. In the current public prototype, the FPGA supplies entropy while host software uses it to vary an SMT-contention workload. That is an experimental host-plus-device design, not an FPGA interposed in the CPU execution pipeline.

Why mitigation is layered

Microcode is only one control in a larger defense:

Write secret-handling code for constant-time behavior. This is AMD's recommendation for the scheduler-contention class.
Apply vendor firmware and OS mitigations. Intel's SMoTherSpectre guidance names STIBP as a mitigation for the documented port-contention attack.
Control sibling-thread exposure. Linux documents SMT disablement and core scheduling among its cross-thread attack controls.
Add workload-specific monitoring or noise only after measurement. Noise can raise an attacker's sample cost, but it does not make variable-time code constant-time or remove every channel.

An FPGA-assisted control may become a complementary layer for a defined threat model. It must be evaluated alongside these existing mitigations, not presented as a replacement for them.

What a hardware-boundary mitigation looks like

A USB or PCIe FPGA peripheral does not sit physically between the CPU's execution ports and a workload. It cannot directly intercept internal scheduler, cache, branch-predictor, or execution-port contention. The public Lavalamp prototype instead combines device-generated entropy with a host daemon that creates controlled sibling-thread activity.

The research hypothesis is narrower:

An FPGA supplies an external entropy stream
Host software maps that stream into a defined contention or scheduling pattern
A benchmark measures whether the chosen attack loses statistical power
The same benchmark records CPU, latency, energy, and workload overhead

No public independent report is linked as of this update. An NDA engagement is not evidence readers can verify. Until a report publishes methodology, hardware, software, baselines, confidence intervals, and raw-enough results to reproduce, leakage reduction and overhead remain hypotheses.

The three Lavalamp tiers

The project has described three possible form factors. These are roadmap concepts, not a statement of commercial availability or validated mitigation:

Lavalamp Lite — USB

Consumer-grade USB FPGA device. Plug-and-go. Target use cases: cryptographic workstation operators, high-security personal devices, and anyone who wants the mitigation on a single machine without infrastructure.

Lavalamp Pro — PCIe

PCIe card form factor. Target use cases: servers running cryptography, VDI endpoints, exchanges, and any production workload where the mitigation needs to be on every machine in a rack.

Lavalamp OEM — IP-Core Licensing

The masking stack as licensable IP for integration into a customer's own ASIC or FPGA design. Target use cases: integrators building security-oriented appliances, firms building post-quantum inference appliances, or operators needing the mitigation baked directly into custom silicon.

What Lavalamp can and cannot claim today

A realistic post should be precise about what's claimed and what isn't:

Research targets, not guarantees:

A measurable reduction in a named attack's success rate or information leakage
An overhead profile that is acceptable for a defined workload
Compatibility across tested CPU, OS, firmware, and scheduler configurations
Clear behavior when the device, daemon, or entropy stream fails

What Lavalamp does not claim:

It is not a cryptographically zero-leakage device, and no public result currently establishes an order-of-magnitude reduction.
It is not a replacement for well-constructed constant-time cryptographic code. If the prototype eventually demonstrates measurable signal reduction for variable-time code, that would still not make the code constant-time.
It is not a substitute for OS hardening, firmware, isolation, core scheduling, or operational security.

Coverage areas

Lavalamp targets four specific operating environments documented on the public site:

Shared cloud infrastructure — where co-residency depends on provider architecture, instance type, tenancy controls, and scheduling; it is not guaranteed in every deployment
Browser workloads (WebAssembly) — where untrusted client code executes in the browser's sandbox, which is itself subject to micro-architectural timing leakage
VDI / Citrix — where shared physical hardware runs multiple user desktops and cross-tenant leakage is a threat-model concern
Post-quantum primitives — ML-KEM was standardized in NIST FIPS 203; implementation side-channel research continues, but an FPGA noise layer does not replace constant-time implementation review

High-value financial infrastructure (exchanges, custody, signing) is a named target market for the Pro and OEM tiers but runs inside the four coverage areas above — typically VDI-managed workstations for signing operators and cloud or on-prem servers for automated systems.

When to prioritize hardware mitigation

The honest framing: most workloads do not need Lavalamp. Most adversaries are not sophisticated enough to mount productive side-channel attacks, and most secrets are not valuable enough to justify the attack cost.

Lavalamp is for the workloads where both conditions fail:

The adversary is sophisticated — nation-state, well-funded financial attacker, organized APT
The secrets are valuable — cryptographic keys, biometric templates, exchange signing material, patient data, classified data

If your workload is in that category, start with a threat model, constant-time review, current firmware, OS controls, tenant isolation, and measurement of the relevant channel. An FPGA-assisted control should be prioritized only if a reproducible evaluation shows incremental risk reduction for that environment.

Where this goes next

Public independent benchmark — required before performance claims
Tier-specific deep-dives on Lite, Pro, and OEM — upcoming
Project Lavalamp product page for current status and contact

A public benchmark is the critical next milestone. It should identify the exact attack, victim code, CPU and firmware, sibling placement, OS controls, sample count, statistical test, overhead, failure modes, and comparison against constant-time code, STIBP, SMT disablement, and core scheduling.