The real threat is cache timing on shared L3, not speculative execution

Yuki N. · 2026-06-22T13:24:28Z

The focus on speculative execution flaws like Spectre in our enclave threat models is a distraction. While those attacks are real, they require precise phasing and often depend on specific shared execution contexts that our hardened kernels already serialize. The persistent, architectural weakness we are not mitigating adequately is deterministic cache timing on the shared last-level cache, specifically L3. Our current IronClaw deployments on x86-64 platforms utilize SGX enclaves or SEV-SNP VMs, but both are vulnerable to cache-based side channels because the L3 cache is physically shared between the enclave/VM and the untrusted host. Memory accesses, even from within a protected environment, leave traceable footprints in this shared resource. An adversarial host process with sufficient resolution can perform Prime+Probe or Flush+Reload attacks on the L3 to infer activity patterns. This isn't about speculative misprediction; it's about direct observation of a shared hardware resource. Consider a scenario where the enclave is processing a sensitive dataset, and the access pattern to that data is data-dependent. A simple binary search on encrypted indices, or a decision tree evaluation, can leak the operation through cache line evictions. The host doesn't need to read your data; it just needs to see which cache sets are active and when. Our current NEAR AI mitigations, as documented in the internal `sec-0034` memo, are insufficient: * **Cache Line Coloring (Software):** We implement a form of this, but our static partitioning is too coarse. It reduces the effective cache size but does not eliminate contention within the assigned color if the host can profile it. * **Memory Access Pattern Obfuscation:** The library we use (`libobfuscate`) adds random delays and dummy accesses, but its entropy is seeded from the enclave's own RNG, which becomes predictable over time under sustained probing. * **No Hardware Enforcement:** We have no guarantees from the CPU that our cache partitions are respected at the hardware level. The `PCONFIG` instructions for Intel CAT are not deployed on our production platforms. We need to shift our assessment. I propose a concrete test to demonstrate the exposure. Deploy a minimal enclave with a known data-dependent access pattern (e.g., a lookup in a 256-element array based on a secret byte). Then run a calibrated host-side attacker process on the same physical core, sharing the L3. Use `perf` events (`LLC-load-misses`) or direct `rdpmc` instructions to measure cache set contention. Sample attacker skeleton for the host (Linux): ```c #define CACHE_SET_SELECTOR 12 // Target a specific cache set #define ARRAY_SIZE (256 * 64) // 64 bytes per cache line static volatile char *probe_array = mmap(...); void prime_set(int set_index) { for (int i = 0; i < ARRAY_SIZE; i += CACHE_SETS) { probe_array[i + set_index] = 0; } } uint64_t probe_timing(int set_index) { uint64_t before = __rdtsc(); volatile char dummy = probe_array[set_index]; uint64_t after = __rdtsc(); return after - before; } ``` If the timing for `CACHE_SET_SELECTOR` shows statistically significant variance correlating with the enclave's secret byte value, the threat is confirmed. The research priority should be: * Evaluating Intel CAT/MPK or AMD's equivalent for enforceable hardware partitioning. * Moving sensitive routines to algorithms with constant-time memory access patterns, not just obfuscated ones. * Investigating L3 cache flushing on enclave entry/exit, despite the performance cost. We are securing the software supply chain with Sigstore and SBOMs, but our runtime hardware assumptions are flawed. A verified binary running in a compromised cache environment is still compromised. -Yuki

Summarize Topic

Page 2 / 2 Prev

Side Channel Risks in Enclave Deployments

Last Post by Raj Host 1 week ago

16 Posts

16 Users

0 Reactions

9 Views

RSS

Raj Host

(@selfhost_raj)

Eminent Member

Joined: 1 week ago

Posts: 22

Translate ▼

June 24, 2026 4:42 am

Right on. The L3 is an open microphone in the room. Even SEV-SNP's "protected" VMs are just yelling into it a bit more quietly.

Your binary search example is the perfect illustration. It's not just about crypto, it's about any control flow that branches on secret data. I've seen this bite people who think moving a database index lookup into an enclave is safe.

So the real question becomes: what ops are even *possible* in that model? A full linear scan every time? It pushes you towards specialized hardware or a complete re-architecture, like that library-only approach others mentioned.

Selfhosted since 2004

ReplyQuote

Page 2 / 2 Prev

80 Forums
1,238 Topics
7,436 Posts
0 Online
508 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed