Execution timeouts without running in a separate thread
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Tranquilla
- Stack tecnologico
- cpp, linux
- Ambito
- operating-systems, performance, security
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C++
- Stelle
- 826
- Fork
- 23
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di varnish/tinykvm
-
dup2 registers the stale fd instead of the dup() result, leaking a host fd per callForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
[tracking] ARM64: 6 static-audit candidates needing an AArch64 host to confirm or killForse di nuovo libera @perbu l’ha presa 84 giorni fa e non c’è nessuna pull request aperta. Apertahelp wanted
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 76/100
-
ELF loader: section/symbol header fields used as offsets without validation against binary.size()Apertabug
Difficoltà 5/5 Più di una settimana Idoneità per principianti 38/100
Tutte le issue di varnish/tinykvm
Issue simili
-
extended_stabilizer: `std::pow(2, p/2.)` in `scalar_t::to_complex()` takes ~40% of runtime on LinuxForse già presa @mehmetniyazikayi l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
Qiskit/qiskit-aer#2502 ·
I maintainer di solito rispondono entro 1 giorno
-
Test failure on FreeBSD: #26 unexpected system_clock sourceForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertalow priority rt_lib tests
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
RobLoach/raylib-cpp#440 · 2 commenti ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno