Exécuter du code suspect en sandbox : smolvm teste ses limites

Pourquoi une sandbox matérielle ?

Les conteneurs Docker qu'on connaît ? Ils partagent le kernel avec l'hôte. Si ton code non fiable trouve une faille, il s'échappe. smolvm dit non : chaque exécution tourne dans sa propre VM Firecracker, complètement isolée.

Ce qu'on a testé

Simon Willison (créateur de datasette) a demandé à Claude de pousser smolvm dans ses retranchements. L'idée : faire tourner du Python et du JavaScript suspects, vérifier que rien ne peut fuir.

Résultat :

• ▸Pas de réseau : même si le code essaie, c'est bloqué au niveau VM
• ▸Limites strictes : tu dis "max 512 MB de RAM", la VM tue tout ce qui dépasse
• ▸Timeouts guest : même une boucle while True s'arrête proprement
• ▸Fichiers cloisonnés : les entrées en lecture seule, les sorties dans une zone dédiée

Le piège : Claude était elle-même enfermée

Claude Code (l'environnement IA de web) tourne lui-même dans une VM Firecracker... sans prise en charge de la virtualisation imbriquée. Impossible de lancer smolvm dedans.

Solution créative ? Utiliser GitHub Actions (qui expose /dev/kvm) comme banc de test. Claude a mis en place un workflow temporaire, lancé les tests, récupéré les logs, puis nettoyé derrière.

Les chiffres

• ▸Démarrage froid : 0.6–1.5 secondes (correct pour un cas d'usage asynchrone)
• ▸Exécution chaude : ~50 ms (acceptable pour du temps réel)
• ▸Overhead : minimaliste grâce à Firecracker (VM ultra-légère)

Qui devrait s'y intéresser ?

Platformes où les utilisateurs apportent du code personnalisé : éditeurs visuels, outils de pipeline de données, places de marché de workflows. Aussi : les équipes qui veulent faire confiance à des développeurs externes sans trembler.

Les limites réelles

Pas de GPU (tu dois passer par des appels réseau). Pas de persistance entre exécutions. Le débogage n'est pas trivial quand quelque chose déraille. Mais pour de la transformation de données ou du code métier côté utilisateur, c'est solide.