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.1
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
}
#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.
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.1
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#13382 introduced checks for some of the
arrayoperations, 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 thinkarray.newand its ilk are still not checked, but I haven't verified that.Footnotes
"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. ↩