Execution timeouts without running in a separate thread
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 821
- Forks
- 23
- PR merge metrics
- No merged PRs in 30d
Description
Just a thought after reading your excellent paper:
No matter which sandbox solution you chose, you will probably run the sandbox in a separate thread in order to have execution timeouts. Therefore, there will be overhead related to thread communication in most solutions. This latency will usually be approximately the same whether you run TinyKVM, V8 or wasmtime,
This isn't strictly accurate:
-
Wasmtime has a timeout mechanism that makes running on the same thread safe: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.epoch_interruption
-
While with V8 one could avoid the thread communication overhead by running on the main thread and calling
v8::Isolate::TerminateExecution()with a timer from a watchdog thread. https://v8.github.io/api/head/classv8_1_1Isolate.html#ad212b2e0b66ff5d586cd79cfa0b555fb
So I wonder if TinyKVM implement a similar mechanism and I see you have already explored setting a timer in the virtual hardware here but found it to be slow. https://stackoverflow.com/questions/68590696/timeout-for-kvm-userspace-guest)
As I understand it an interrupt will cause a VMExit which will return control back to the VMM. This suggests installing a no-op signal handler on the thread running the kvm guest will give back control: https://gist.github.com/mcastelino/df7e65ade874f6890f618dc51778d83a
Perhaps this could even just be set with setitimer or SIGALRM so you wouldn't need a watchdog thread.
Of course for most many cases using a thread pool will still be desirable but the lower latency of running in thread like this could be useful for sandboxing routing logic where the thread switching overhead might be noticeable.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting the existing virtual-hardware timer approach and the KVM guest execution path; the issue does not name specific files or tests. Investigate whether setitimer/SIGALRM or a signal handler can safely interrupt same-thread execution, and define done through reliable timeout behavior and latency measurements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- operating-systems, performance, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100