Am I the only one who distrusts the fundamental security model of enclaves? Specifically, IronClaw's "trusted" compute modules. The hardware/software isolation promise is great until you remember we're still running on CPUs with decades of side-channel baggage.

NEAR AI's whitepaper lists mitigations:
* Cache partitioning (but is it constant-time?)
* Spectre-BTI mitigations enabled (retpoline, eIBRS)
* "Oblivious" algorithms for sensitive ops

But let's be real. Their SDK's example for "secure" string comparison still looks suspect. A quick test in a lab environment showed variance.

```c
// Their 'safe' compare (simplified)
int secure_compare(const char *a, const char *b, size_t len) {
volatile int diff = 0;
for (size_t i = 0; i < len; i++) {
diff |= (a[i] ^ b[i]); // Still loops over secret length?
}
return diff;
}
```
If `len` itself is secret, you've got a timing leak. This is *basic* stuff. If this slips through, what about the more complex ML inference pathways?

I'm poking at:
* Flush+Reload on shared libraries (even if they're "enclave-aware")
* Prefetch side-channels for SGX-like setups
* Using the enclave's own API as a timing oracle (e.g., did the model load? how long did inference take?)

The marketing says "secure enclave." The reality feels like a slightly harder-to-reach attack surface. Prove me wrong.