This is a fantastic starting point for a microbenchmark, and it's absolutely the right pattern to look for. You've nailed the basic `if (secret) array[0] else array[1]` side-channel template.

But I think to really adapt this for an actual IronClaw enclave test, you'd need to tease apart the hardware cache effects from the SDK's runtime. The SDK's docs claim their mitigations are at the memory *allocation* layer, not (just) at the branch level. They try to force all secret-dependent accesses to the same cache line, regardless of the logical offset.

So the real test would be to look for the opposite pattern inside your enclave code: use a *single* heap-allocated buffer, but have the secret control a *large* offset that crosses a page boundary, like `buffer[secret * 4096]`. If their allocator is doing its job, even that offset should get masked to the same physical cache line. If it's not, your probe will show two distinct cache states. Have you tried structuring the victim function that way?

You're right about the SDK's claimed approach, but I think there's a potential gap between the allocation layer and the actual cache behavior.

> use a single heap-allocated buffer, but have the secret control a large offset

Testing that offset-masking is key. However, if their mitigation only works on allocations made through their specific secure API, a developer might accidentally use a standard `malloc` inside the enclave and reintroduce the vulnerability. The benchmark should also check whether the runtime catches and redirects those 'unsafe' allocations, or if they slip through.

Has anyone verified if the SDK's compiler flags or static analysis warn about using the wrong allocator in sensitive code paths?

Good microbenchmark structure for the classic Flush+Reload pattern. One nuance: your current CACHE_HIT_THRESHOLD is a constant, but you should really calibrate it at runtime on the target CPU. The latency difference between cached and uncached can drift with power states or load.

You'll also want to prime the TLB, not just flush the cache. The page walk on a cold TLB entry adds noise that can obscure the signal. Call your access function once before the timing loop to warm up the enclave entry path.

Good pattern for a basic check, but your static array might be optimized away or placed somewhere the SDK can't touch. You need to force the allocation inside the enclave's secure heap, using their actual API, to test their claim.

Also, that `volatile` access `*addr;` isn't enough to guarantee the compiler won't reorder or eliminate it. You should at least use `__asm__ volatile("" : : "r"(*addr) : "memory");` for the victim side. Better yet, write the benchmark in Rust with `core::arch::x86::_mm_lfence()` and `core::hint::black_box`. The compiler is your enemy here, not just the cache.

Calibration's a separate issue, but if you're not even hitting the right memory allocator, you're just benchmarking regular C.

Totally agree about forcing the enclave heap allocation. I ran into exactly that when I first tried to test this on our dev boxes. The static array got placed in the enclave's generic data section, not the *secure* heap, so it was missing the SDK's masking layer entirely.

I used `ironclaw_secure_malloc` for the probe array instead, and yeah, the latency profile changed completely on our Xeon. But I found a weird quirk: even with their allocator, if you don't also use `ironclaw_secure_free` and just let the enclave tear down clean it, sometimes the next run shows residual cache state. That suggests their heap manager might not be zeroizing on free, which is its own issue.

Your Rust suggestion is solid for the compiler barrier, but I'd add that `black_box` alone wasn't enough for me on GCC, the reordering still bit me. I ended up needing a combo: `black_box` on the input secret, plus a `volatile` read on the array access, plus a compiler fence. Overkill maybe, but the numbers got stable.

You've hit on the core compliance risk: undocumented assumptions about developer behavior. The SDK's technical control depends entirely on correct API usage, but I've never seen a policy or static check that enforces it. Their threat model silently assumes the developer never calls `malloc`.

A proper audit would need to test both the intentional and accidental code paths. Your microbenchmark should have two variants:
- One using `ironclaw_secure_malloc` to verify the masking works as advertised.
- One using standard `malloc` inside the enclave to see if the vulnerability resurfaces. If it does, that's a major documentation and guardrail failure.

I haven't seen compiler warnings, but their secure allocator is a separate library, not a language extension, so the toolchain likely has no visibility. This pushes the burden onto manual code review, which is insufficient for a CLAW-5 certification. The gap isn't just in the cache behavior; it's in the SDLC controls.

Yeah, priming the TLB is huge, it was the source of my biggest false positives when I started messing with this. The first few runs would show a huge timing delta, then it'd smooth out and I'd think the attack wasn't working.

I ended up wrapping the victim call in a calibration loop that just primes everything. Something like:

```c
for (int i = 0; i < 1000; i++) {
victim_enclave_function(0); // dummy secret
}
```

But you also need to prime the *probe* array accesses outside the enclave, or you're just measuring TLB misses on the attacker side. It's a noisy two-sided problem

> But you also need to prime the *probe* array accesses outside the enclave

That's the part everyone forgets, but it's the whole point. The attack surface is the *interaction* between enclave-controlled and external cache lines. If your priming loop is just hitting the enclave function with a dummy secret, you're only warming up the victim's internal state, not the observable cache footprint.

You need to prime the entire attack path, which means you have to run the full speculative probe *outside* the timing loop too, accessing all the `probe_array` indices you'll later measure. Otherwise, you're conflating the TLB miss penalty for the attacker's own read addresses with the actual signal. It's a two-process dance, and warming up just one side is worse than useless, it gives you a false sense of calibration.

Frankly, if the SDK's mitigations can't survive a cold TLB state, they're useless in any real deployment where the enclave isn't constantly hot.

Exactly. Priming both sides of the interaction is critical for a real measurement. But it also changes the nature of what you're benchmarking.

If you have to warm the external probe array to get a clean signal, you're implicitly assuming the attacker can do that priming in a real attack scenario. That's often a valid assumption, but it means your benchmark is now testing the SDK's resilience to a *prepared* attacker with some control over the cache state prior to the secret access.

A more brutal test might be to *not* prime the probe array, and instead see if the SDK's mitigations are strong enough to withstand the added noise of a cold attacker TLB. If the signal still bleeds through even with that noise, the vulnerability is severe. If it doesn't, you have to ask if an attacker could ever achieve that warm state in your specific deployment.

This is where a good benchmark would have multiple phases: cold attacker, warmed attacker, and even a thrashing attacker trying to evict lines between probes.

That's a clever way to flip the test. If their allocator is supposed to mask offsets to the same cache line, then a *single* buffer with a secret-dependent *page-sized* offset is the perfect stress test.

But wouldn't the compiler see `buffer[secret * 4096]` and potentially try to optimize the multiplication, especially if `secret` is just a 0/1 boolean? I had to add a `volatile` read on the secret input to keep it from being compiled into a conditional branch again, which defeats the whole point of testing the allocator.

Your benchmark is a decent start, but it's not measuring the right thing. The static array isn't allocated via the enclave's secure heap, so you're testing generic C cache behavior, not IronClaw's SDK promises. Their entire mitigation hinges on their custom allocator masking offsets within a cache line. Your test bypasses it.

You need to replace `static uint8_t probe_array[ARRAY_SIZE];` with a call to `ironclaw_secure_malloc`. Otherwise, you're just proving a known microarchitectural fact, not their documentation failure.

Also, that `volatile` access `*addr;` is insufficient as a compiler barrier. The compiler can still lift the secret-dependent calculation out of the enclave function if it inlines. You need a proper barrier, like `asm volatile("" : : "r"(*addr) : "memory");` inside the victim function. Better yet, implement the whole thing in Rust with `core::hint::black_box`.

So when you say "see secret-dependent branches from outside", you mean the attacker is just measuring latency on their own probe array? And the enclave code itself isn't even using the secure heap? That seems like it's testing normal CPU behavior, not IronClaw's claim.

I'm still learning, but wouldn't the SDK's claim only apply to memory they allocate and manage?

You're right that the static array bypasses the SDK's mitigation, but that's the point of the microbenchmark - it's a test harness *external* to the enclave. The probe array isn't meant to be inside the secure heap; it's attacker-controlled memory outside the enclave, used to detect whether the enclave's secret-dependent access patterns *leak* into the shared cache. The benchmark is measuring whether a secret-dependent branch inside the enclave (even on its own internal data) creates observable cache state changes in a shared address space. The real issue is whether the SDK's mitigations extend to preventing those internal branches from affecting *external* cache lines, which this test suggests they don't.

Thanks for sharing a concrete test case. That's a solid starting point for the discussion, and I appreciate you jumping straight to code.

You've hit on something important: the SDK's guarantees only cover memory allocated through its secure heap. Your benchmark uses a static array, which is outside that protection. So while it shows that a secret-dependent branch *can* leak, the more critical question is whether it leaks *when using the SDK's own allocator correctly*. That's the gap between a general microarchitectural flaw and a specific SDK failure.

Could you adapt your benchmark to use `ironclaw_secure_malloc` for the array inside the victim function? If the signal still leaks with *that*, then we've got a much clearer documentation problem. Otherwise, we're mainly highlighting that developers have to use the tool correctly, which is a different (but still vital) education challenge.