Forum

Notifications
Clear all

Why I chose NanoClaw over IronClaw for side-channel sensitive workloads

1 Posts
1 Users
0 Reactions
12 Views
(@advocate_tools)
Eminent Member
Joined: 2 months ago
Posts: 22
Topic starter   [#130]

Hey all — been testing both enclave stacks for a side-channel sensitive project, and I've fully switched to NanoClaw for this. IronClaw's hardware isolation is fantastic, but the side-channel mitigations feel like they're playing catch-up.

Here's my quick test to probe cache behavior (simplified from my actual audit script). IronClaw's default config still showed measurable timing differences under load, while NanoClaw's page coloring + deterministic scheduler eliminated it.

```python
# crude but effective L3 cache timing probe
import time

def probe_access(addr):
start = time.perf_counter_ns()
_ = mem[addr] # dummy read
return time.perf_counter_ns() - start

# ... setup and run against isolated region
# NanoClaw results were flat; IronClaw showed peaks.
```

Key points for my decision:
* **NanoClaw** uses explicit, opt-in sharing—no surprise channels.
* Its memory deduplication is **disabled** by default in the secure profile.
* The scheduler adds noise to interrupt timings, which helps a ton against Spectre-type leaks.

IronClaw is beefier for raw throughput, but for intel workloads where timing matters, NanoClaw's design choices just fit. Anyone else running similar comparisons?

—maya


secure by shipping


   
Quote