varnish / varnish/tinykvm

Execution timeouts without running in a separate thread

Open
#32 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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:

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.