Runtime limits on "bad neighbors".

[rhomber]

As discussed on Discord (I'm Lyran Sage). We'd love to see some features added that can prevent untrusted code from preventing the execution of other tasks. It's our goal to be able to run several user provided scripts on the same thread at the same time (probably a runtime per execution).

To enable this to work and limit a single script from "blocking" the thread we need to have configurable limits on:

1. Loops, to prevent "while(1)" attacks.
2. Recursion or stack depth. Ideally based on stack depth.

Anything else that you guys can think of that could possibly lock up execution? I think the above two covers everything though really?

Thanks so much!

David

[addisoncrump]

The VM fuzzer PR (#2401) adds a mechanism for restricting the number of instructions. Could probably be used to complete (1) here.

[y21]

Memory limits might also be worth adding to the list (unless this already exists), otherwise one bad actor can OOM the whole process and bring all other scripts with it.

Also, I don't think limiting bytecode instructions is a good/reliable way to guard against lock ups, since this has no effect on native builtins.
For example, RegEx execution happens in native Rust code for the most part, and code abusing catastrophic backtracking will get the engine stuck in native code for a long while:

use boa_engine::Context;
fn main() {
    let mut cx = Context::builder().instructions_remaining(500).build();
    dbg!(cx.eval("/(a+)+b/.test('a'.repeat(31) + 'c');"));
}

This piece of JS code uses 13 instructions until it gets stuck.

There are plenty of other builtins that spend all of their time in native code and given long and complicated strings, can easily lock up the engine. Another example is BigInt('1'.repeat(1e7)).

[HalidOdat]

If no body is working on Loops, to prevent "while(1)" attacks., I'll try to solve this :)