sandbox: give a script its own heap with an exact memory limit #1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
A sandboxed script's memory limit counts what the script holds (live bytes), not what it has ever allocated, and the memory of a script that stopped is given back at teardown. Today
torb_sandbox_accountonly adds allocated bytes (runtime/sandbox.c), becausefreedoes not know a block's size, so a script that churns through garbage hits the limit while holding almost nothing, and a stop leaks what the script held (SCRIPTS.md section 4 "Memory is allocation, not residency, for now", section 6 "A stop leaks what the script held").Implements
memoryfrom the sandbox's own heap (its own allocator, so the limit is exact and the teardown is one free)"; SCRIPTS.md wins where they differ.Acceptance criteria
Proposed against the recommended option of the owner decision below; they are final once it is answered.
torb_allocate,torb_raw_allocate, sized bytorb_platform_allocation_sizeas the counted memory limit ofruntime/memory.calready does) are the number checked against thememorylimit. A block freed while the sandbox is open gives its bytes back; a block that was allocated outside the sandbox never counts, and freeing it never lowers the count. Exact in the VM (torb run,torb test) and in a native binary that hosts scripts (--embed-vm, the script host).SandboxError"The script allocated more than N bytes", never the process (compiler/tests/sandbox.test.trb, both cases, exact byte boundary).Process.exit) script's blocks are freed at teardown where nothing outside the sandbox holds them; a test showstorb_live_block_countback at its value before the script ran (VM-only conformance program or runtime test).tests/conformance/sandbox-crossing.trbandtests/conformance/vm-only/sandbox-*.trbstay green; tier A and tier B gates green (runtime/and the VM change).build/release/torb.exe docs skill docs skillsregenerated if a skill page changes.Seed
Expected: does not touch the seed. No syntax change, no new native (the kernel operations
SandboxOpen/SandboxCloseexist; a change to them is an operation, SCRIPTS.md section 5), no new driver flag, no std name looked up by string. The work isruntime/memory.c,runtime/sandbox.c,runtime/machine.cand the VM's TorbScript where it calls them. If the implementation needs a new native or a changedstd/sandboxname the compiler looks up, it stops and files a seed question instead of going on.Size
One PR, landing as two Conventional Commits:
feat(runtime): count the live bytes a sandboxed script holds(accounting plus the exact-limit tests) andfeat(runtime): free what a stopped script held at teardown(teardown, the leak-count test, docs). Owner of the change:runtime/and the VM, so an opus/high worker. No split needed.Status
Waiting on the owner decision in the comments: what "teardown frees" may mean for a block the host still reaches (SCRIPTS.md section 5 passes the value by reference inside one VM), and whether slice 6 is a real arena allocator or accounting over libc's heap.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). Implements SCRIPTS.md slice 6 and ROADMAP milestone 7; the design record settles the goal. No collision with a design record or CONCEPT "Open Questions". Touches
runtime/and the VM (opus/high worker when implemented); seed impact to settle in refine. Release freeze for 0.1.0 (2026-10-06) holds new PRs, next: refine (buffer already >= 2 ready, so queued)[loop:torbscript] claim refine by session:loop-torbscript-20261007 until 2026-10-07T13:13:06Z
[loop:torbscript] owner decision:
What. SCRIPTS.md slice 6 and BACKEND 5.4 say "own heap: exact limit, teardown is one free", but no design record says how a block that the script allocated and the host still reaches is treated. SCRIPTS.md section 5 decides that inside one VM the value is passed by reference and "the script configures the caller's value in place": lists, texts and boxes the script allocates end up inside the caller's value, on a normal return and also on a stop (the frames are abandoned, the value stays as the script left it). A literal "teardown frees every block of the sandbox" would leave the caller with dangling blocks. A native binary that hosts scripts is different: only text crosses (section 5), so there the sandbox's blocks are never shared.
Options.
free(everyfreesite ofmemory.clearns the owner). Largest change, touches the layout contract between runtime and VM.torb_platform_allocation_size, as the counted memory limit already does); a free of a recorded block subtracts its bytes, a free of any other block never does. The limit is exact in live bytes. On a normal close the surviving blocks are handed to the host (the table is dropped, they are ordinary blocks). On a stop: native host (slice 8, value crossed as text): everything still recorded is freed, the criterion "live-block counter back to its value before the script ran" holds. Program the VM runs (value by reference): blocks the script allocated stay valid because the caller's value may reach them, and what an abandoned frame held is freed only where its count shows nothing else holds it; a leak bounded by the limit remains in that one case and is documented (as section 6 says today for all cases). No change to the value-passing decision of section 5, no ABI change, no seed impact.Recommendation. Option 2. It delivers the exact limit everywhere, the full teardown where the host shares nothing (the case a server or an embedded script host has), and does not reopen section 5. If you prefer a clean break instead, option 1 with copy-out at close is the honest "own heap", at the price of a larger change and a revised section 5. Once you answer (comment here, or relay it from the TorbScript group), I set
readyand the acceptance criteria in the issue body become final.[loop:torbscript] refine: rewrote the body to the definition of ready (goal, criteria, SCRIPTS.md slice 6 / ROADMAP milestone 7 / BACKEND 5.4, seed: not expected, size: one PR in two commits). The design records leave open how teardown treats blocks the host still reaches (value passed by reference inside one VM) and arena vs accounting over libc; filed the owner decision above with a recommendation. No
readylabel until it is answered. Tokens used ~90000, next: waiting (owner decision)[loop:torbscript] wait: owner decision of comment 504 (blocks teardown of host-reachable blocks, arena vs accounting) is still open since 2026-10-07; nothing to do until Torben answers. Re-check 2026-11-06.