Stream: git-wasmtime

Topic: wasmtime / issue #13387 Should we add fuel/epoch checks i...


view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 16:34):

fitzgen opened issue #13387:

These cannot lead to infinite loops since they are still bounded, and therefore are not DoS CVEs, but they could block for longer than usual and lead to spiky latencies.[^spiky]

[^spiky]: "No spiky latencies" is not something we provide guarantees around already, since we only insert checks at loop headers and function calls, so e.g. large basic blocks without those things can have similar behavior.

FWIW, we needn't necessarily add checks on every byte copied in a memory.copy, which would impose horrendous overheads. What we could do to address this instead is have a max size on the chunk of data we are processing all at once without interruption checks and then effectively emit code like

for chunk in block.chunks(MAX_CHUNK_SIZE) {
    check();
    process(chunk); // <--- the current hot loop or memmove/memcopy libcall
}

https://github.com/bytecodealliance/wasmtime/pull/13382 introduced checks for some of the array operations, but IIUC not all of them and also for the ones it does it inserts epoch checks on every loop iteration, rather than doing the chunking suggested above. I think array.new and its ilk are still not checked, but I haven't verified that.

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 16:34):

fitzgen added the wasm-proposal:gc label to Issue #13387.

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 18:56):

alexcrichton commented on issue #13387:

IMO "yes", and I've got a PR for this after #13382

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 19:15):

alexcrichton commented on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 23:33):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 15 2026 at 23:40):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 16 2026 at 00:03):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 16 2026 at 00:03):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 16 2026 at 00:03):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 16 2026 at 18:26):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2026 at 06:13):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2026 at 06:13):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2026 at 06:13):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2026 at 06:13):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 05:46):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 21 2026 at 21:55):

alexcrichton edited a comment on issue #13387:

A checklist of instructions to handle:

view this post on Zulip Wasmtime GitHub notifications bot (May 22 2026 at 17:31):

cfallin closed issue #13387:

These cannot lead to infinite loops since they are still bounded, and therefore are not DoS CVEs, but they could block for longer than usual and lead to spiky latencies.[^spiky]

[^spiky]: "No spiky latencies" is not something we provide guarantees around already, since we only insert checks at loop headers and function calls, so e.g. large basic blocks without those things can have similar behavior.

FWIW, we needn't necessarily add checks on every byte copied in a memory.copy, which would impose horrendous overheads. What we could do to address this instead is have a max size on the chunk of data we are processing all at once without interruption checks and then effectively emit code like

for chunk in block.chunks(MAX_CHUNK_SIZE) {
    check();
    process(chunk); // <--- the current hot loop or memmove/memcopy libcall
}

https://github.com/bytecodealliance/wasmtime/pull/13382 introduced checks for some of the array operations, but IIUC not all of them and also for the ones it does it inserts epoch checks on every loop iteration, rather than doing the chunking suggested above. I think array.new and its ilk are still not checked, but I haven't verified that.


Last updated: Jun 01 2026 at 09:49 UTC