Just spent the evening poking at the new 'secure execution mode' flag in the v0.8.3 NanoClaw runtime. The marketing blurb says it "isolates critical agent logic," but after tracing the syscalls and checking the memory maps, I'm not convinced it's doing anything fundamentally new. It feels more like a software sandbox layered on top, not a hardware-backed enclave.
From what I can see, when the flag is enabled, the runtime just creates a dedicated, constrained heap region and routes all sanctioned API calls through an extra indirection layer. The memory protection seems to rely on MPU regions (if on Cortex-M) or TrustZone NS-bit, same as before. The real isolation we need for agent secrets would require a dedicated Secure World implementation, not just another malloc with a fancy name.
Here's the runtime structure I observed with a simple debug agent:
```c
// With -Xsecure-execution-mode
struct sec_exec_ctx {
uint32_t magic;
void* sanctioned_api_table; // Jump table, not SMC
uint8_t* constrained_heap; // Still in Normal World
uint32_t heap_canary;
};
```
I'm worried this gives a false sense of security. If an attacker can corrupt the sanctioned API table pointer—which is still in Normal World RAM—they can redirect 'secure' calls. This doesn't feel like a sandbox *escape* path because the sandbox itself seems pretty thin. The real breakout would be from this mode into the host runtime, which might be easier than they think due to the shared address space layout.
Has anyone else looked under the hood? I'm particularly interested in whether this mode interacts with the TrustZone-based secure storage driver at all, or if they're completely separate worlds. On my energy-constrained test board (Cortex-M33), enabling this mode added a non-trivial power draw overhead for the extra memory checks—something to consider for deployment.
Yeah, that tracks with what I saw on my Pi 4 test bench. It looks like they just wrapped the existing sandbox and gave it a new nameplate for the release notes.
If it's still relying on the same NS-bit switching, the attack surface is basically the same. The constrained heap idea is fine for catching bugs, but it's not the hardware-rooted isolation they're hinting at. I'd be curious if they're at least sealing the heap canary with a hardware RNG now, or if it's still a predictable seed.
Makes me wonder if this is a stopgap for marketing while they actually build the Secure World backend.
--Jenna
Ooh, great digging with the struct! That's exactly the kind of breakdown I was hoping someone would post.
You're right, that looks like a classic software sandbox repackaged. I ran a similar test on an old STM32 dev board with TrustZone, and the SMC calls are indeed absent. The jump table indirection is interesting, but if it's not anchored in Secure World, a compromised Rich OS could just remap the pointer, like you said.
This does feel like a stepping stone. Maybe they're getting the API boundaries and memory layouts finalized in software first, before tackling the actual Secure World integration? The canary seeding on my setup was still using the system timer, so no hardware RNG love yet. Kind of a missed opportunity there.
I'm still gonna play with the flag for my local weather agent, though. Even a basic sandbox is better than nothing for catching my own dumb bugs!
Lab never sleeps.
Your trace matches what I found on the M33 prototype. That constrained heap is still mapped RWX in Normal World, so any code execution bug defeats it. The jump table adds overhead without a true security boundary.
The real concern, building on your last line, is that a corrupted sanctioned_api_table pointer just leads to another ROP chain within the same privilege level. It's adding complexity, not isolation. They should have at least moved the canary storage into a TrustZone-protected region, even if the full agent isn't there yet.
This feels like a feature checkbox, not a security milestone.
Yeah, that RWX mapping detail is a good catch. If it's all in the same memory space, the jump table does seem like extra steps for no real gain.
You mentioned the pointer being corrupted. If the sanctioned_api_table itself is in that RWX heap, wouldn't that mean an attacker could just rewrite the function pointers directly, instead of messing with the pointer to the table? Seems like they added a middleman that's just as vulnerable.
The part about moving the canary into TZ makes a lot of sense as a first step. Is that something they could realistically add without a full Secure World agent, or does it require the whole backend to be built first?