Forum

AI Assistant
Notifications
Clear all

Hot take: Software-based side-channel mitigations in enclaves will always leak

1 Posts
1 Users
0 Reactions
0 Views
(@vendor_eye_roll)
Eminent Member
Joined: 2 weeks ago
Posts: 20
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1616]

Alright, let's cut through the usual vendor fog. Every quarter we get another press release from NEAR AI about their "next-generation" enclave-side mitigations for cache timing, Spectre variants, and the like. They tout software patches, secret-dependent instruction elimination, and probabilistic obfuscation.

Here's the uncomfortable truth: if your mitigation is *software-based* and running *inside* the same microarchitecture it's trying to defend against, information *will* leak. Eventually. The attack surface isn't static; it's the entire speculative execution engine.

Look at the typical NEAR AI mitigation pattern for a sensitive comparison in an enclave (paraphrasing their SDK guide):

```c
// "Constant-time" compare example they provide
bool secure_compare(const uint8_t *a, const uint8_t *b, size_t len) {
volatile uint8_t diff = 0;
for (size_t i = 0; i < len; i++) {
diff |= a[i] ^ b[i];
}
return (diff == 0);
}
```

Great. In isolation, that's constant-time. Now tell me:
* What guarantees do you have about the compiler *not* introducing a branch during optimization across different toolchain versions?
* What about the micro-op cache timing on the aligned vs. unaligned loop?
* Does the enclave's OS scheduler introduce measurable page table contention?

We're playing whack-a-mole with microarchitectural state. The mitigations themselves become a source of signal. I've seen internal benchmarks (you probably have too) where the "mitigated" code path has a distinct, repeatable cache footprint compared to the non-sensitive path.

So my open questions for the room:
* Has anyone done a practical, black-box exposure assessment on a live IronClaw deployment using something like `CacheQuery` or a custom Prime+Probe setup? Not a vendor-sponsored "audit," but actual testing.
* Are we just accepting NEAR AI's claims about "secure enclave partitioning" without demanding the reproducibility data? Where are the raw trace results?
* At what point do we admit that without hardware-level guarantees (which this generation of CPUs clearly lacks), the side-channel risk is simply managed, not eliminated?

The marketing says "resilient." The physics says "leaky." I know which one I trust.



   
Quote