Anthropic Simon przetestował smolvm, ale sandbox wciąż potrzebuje warstwy sterowania

Badacz Anthropic Simon Willison przetestował smolvm pod kątem jednego wymagającego celu: bezpiecznego uruchamiania niezaufanego kodu Python i JavaScript bez nadużyć sieci, systemu plików ani zasobów. Eksperyment natychmiast napotkał konflikt. Claude Code for web działał wewnątrz gościa Firecracker, podczas gdy smolvm potrzebował dostępu do sprzętowej wirtualizacji, której ten gość nie udostępniał.

Nie oznacza to, że smolvm był niebezpieczny. Pokazuje natomiast, że ocena microVM wewnątrz innej, ograniczonej maszyny wirtualnej może zakończyć się niepowodzeniem, zanim w ogóle rozpoczną się testy bezpieczeństwa. To rozróżnienie ma znaczenie dla zespołów rozważających skrypty dostarczane przez użytkowników, programy generowane przez AI lub zautomatyzowane przekształcenia danych.

Notatki z badań nad sandboxem ujawniają także większą lukę inżynieryjną. Silna granica maszyny wirtualnej to tylko jeden element bezpiecznej usługi wykonywania kodu. Operatorzy nadal potrzebują wokół niej limitów czasu, rozliczania zasobów, przygotowywania plików, kontroli wyjścia, monitorowania i sprzątania.

smolvm oferuje kilka przydatnych składników. Sieć jest domyślnie wyłączona, obciążenia otrzymują oddzielne jądra gościa, a wartości CPU i pamięci można konfigurować. Funkcje te nie tworzą jednak automatycznie produkcyjnej usługi dla wrogiego kodu.

Prawdziwa rywalizacja nie toczy się więc między smolvm a Dockerem ani między Pythonem a JavaScriptem. Chodzi o zestawienie obietnicy izolacji jednym poleceniem z kontrolami operacyjnymi wymaganymi do niezawodnego wykonywania zadań dla wielu użytkowników.

Test zakończył się niepowodzeniem, zanim uruchomiono niezaufany kod

Pierwszym wynikiem był problem zgodności środowiska, a nie ucieczka z sandboxa ani nieskuteczny limit zasobów.

Willison poprosił model Anthropic działający przez Claude Code for web o zbadanie smolmachines jako szybkiego sandboxa. Proponowane obciążenie było konkretne: uruchamianie kodu dostarczanego przez użytkowników dla zadań takich jak przekształcanie danych strukturalnych.

Ten kod wymagał ścisłych granic. Nie powinien mieć dostępu do sieci, powinien widzieć wyłącznie wskazane pliki, zużywać ograniczoną pamięć i kończyć działanie po czasie określonym przez operatora. Nieskończona pętla, taka jak while true, nie powinna zajmować mocy obliczeniowej bez końca.

Model mógł zbadać projekt i zaprojektować testy. Nie mógł uruchomić maszyn smolvm potrzebnych do ich wykonania. Według relacji Willisona środowisko Claude Code działało już jako gość Firecracker na Linuxie.

smolvm wykorzystuje wspomaganą sprzętowo wirtualizację za pośrednictwem hiperwizorów właściwych dla danej platformy. W Linuxie zwykle oznacza to KVM, interfejs jądra udostępniający monitorowi maszyny wirtualnej funkcje wirtualizacji procesora. Ograniczony gość chmurowy często nie ma urządzenia /dev/kvm niezbędnego do uruchomienia kolejnego gościa akcelerowanego sprzętowo.

To problem wirtualizacji zagnieżdżonej. Maszyna wirtualna może hostować inną maszynę wirtualną tylko wtedy, gdy zewnętrzna platforma udostępnia wymagane funkcje procesora i dostęp do urządzeń. Wiele zarządzanych sandboxów celowo ich nie udostępnia.

Ograniczenie to tworzy nietypowy paradoks testowy. Claude Code for web był izolowany częściowo dlatego, że działał wewnątrz microVM. Ta sama izolacja uniemożliwiła mu uruchomienie innej microVM, którą miał ocenić.

Podczas tej próby żaden istotny atakujący kod Python ani JavaScript nie dotarł do smolvm. Test nie dostarczył niezależnych pomiarów opóźnienia uruchamiania, egzekwowania limitów pamięci, nasycenia CPU, izolacji plików ani zachowania przy kończeniu procesu.

Brak tych dowodów powinien kształtować wszelkie wnioski. Niedokładne byłoby twierdzenie, że ćwiczenie potwierdziło smolvm jako bezpieczną usługę wykonywania kodu. Równie niedokładne byłoby traktowanie zablokowanego uruchomienia jako dowodu przeciwko izolacji gościa w smolvm.

Zamiast tego wynik wskazuje warunek wdrożeniowy. Zespół musi uruchamiać smolvm na zgodnym hoście fizycznym lub na maszynie wirtualnej, która zezwala na wirtualizację zagnieżdżoną.

Oficjalny model bezpieczeństwa smolvm wskazuje KVM jako backend dla Linuxa. Obsługuje również Apple Hypervisor framework i Windows Hypervisor Platform w odpowiadających im systemach operacyjnych.

Taka wieloplatformowa konstrukcja ułatwia lokalny rozwój. Nie sprawia jednak, że smolvm można uruchomić w każdym istniejącym sandboxie agentowym, workerze ciągłej integracji czy środowisku serverless.

W eksperymencie anthropic simon jest to pierwsze istotne odwrócenie sytuacji. Ta sama warstwa izolacji, która chroniła agenta badawczego, uniemożliwiła mu także testowanie drugiej warstwy izolacji.

Anthropic Simon ujawnił brakującą warstwę sterowania

smolvm może zapewnić granicę VM, lecz aplikacja wokół niego musi zdecydować, kiedy kod się uruchamia, co otrzymuje i kiedy kończy działanie.

Projekt opisuje smolvm jako narzędzie wiersza poleceń do izolowanych, przenośnych maszyn wirtualnych Linuxa. Każde obciążenie działa z własnym jądrem gościa za pośrednictwem libkrun, monitora maszyn wirtualnych zaprojektowanego dla lekkich obciążeń.

Ta architektura zapewnia silniejszą domyślną granicę niż zwykły kontener. Konwencjonalny kontener zwykle współdzieli jądro hosta, nawet jeśli przestrzenie nazw ukrywają procesy, sieć i montowania. Gość smolvm otrzymuje oddzielne jądro za granicą hiperwizora.

To rozróżnienie ogranicza bezpośrednią ekspozycję na jądro hosta. Nie eliminuje potrzeby nieufności wobec wszystkiego, co działa wewnątrz gościa. Dokumentacja smolvm wyraźnie stwierdza, że operatorzy powinni traktować konto root gościa jako niezaufane.

Jego domyślne podejście do sieci odpowiada celowi Willisona. Dostęp do sieci jest opcjonalny, więc maszyna uruchomiona bez opcji sieciowej nie powinna otrzymać zwykłej łączności wychodzącej. Gdy aplikacja potrzebuje ściśle ograniczonego ruchu wychodzącego, dostępne są listy dozwolonych hostów.

Udostępnianie systemu plików również jest jawne. Katalogi hosta stają się widoczne tylko wtedy, gdy operator je zamontuje. Umożliwia to stosowanie wzorca katalogu tymczasowego w zadaniach transformacyjnych.

Usługa wykonawcza mogłaby skopiować wskazane dane wejściowe do katalogu tymczasowego. Mogłaby zamontować ten katalog w trybie tylko do odczytu, udostępnić osobną zapisywalną lokalizację na wyniki i usunąć oba po zweryfikowaniu rezultatów.

Istotne jest jednak udokumentowane ograniczenie smolvm. Jego interfejs woluminów montuje katalogi, a nie pojedyncze pliki. Usługa obiecująca dostęp tylko do „wskazanych plików” musi zatem utworzyć izolowany katalog zawierający dokładnie te pliki.

Usługa musi również zabezpieczyć etap przygotowania. Powinna odrzucać dowiązania symboliczne, nietypowe pliki urządzeń, nieoczekiwane uprawnienia oraz ścieżki wychodzące poza zamierzony katalog. Granica VM nie naprawi niedbałego procesu przygotowywania plików po stronie hosta.

Konfiguracja pamięci jest dostępna przez opcję --mem lub Smolfile, deklaratywną konfigurację maszyny smolvm. Udokumentowana wartość domyślna to 8 GiB, a pamięć jest udostępniana przez elastyczny balon virtio.

Elastyczna alokacja poprawia wykorzystanie hosta, ponieważ host nie rezerwuje od razu całej skonfigurowanej ilości. Nie należy jej mylić z kontrolą dopuszczania zadań w przypadku wielu wrogich obciążeń.

Jeżeli usługa uruchamia liczne maszyny gościa z optymistycznymi przydziałami, łączne zapotrzebowanie nadal może przeciążyć hosta. Harmonogram potrzebuje odrębnego modelu pojemności obejmującego pamięć, wirtualne CPU, pamięć masową i liczbę jednocześnie działających maszyn.

Konfiguracja CPU wiąże się z podobnym rozróżnieniem. Przydzielenie jednego wirtualnego CPU ogranicza równoległe wykonywanie wewnątrz gościa. Nie gwarantuje automatycznie, że program otrzyma jedynie ustaloną liczbę sekund CPU.

Jednowątkowa nieskończona pętla może na zawsze zużywać przydzielone jej wirtualne CPU. Hiperwizor ogranicza pętlę, ale zewnętrzny nadzorca musi wymusić limit czasu i zakończyć maszynę.

Systemy produkcyjne zwykle potrzebują zarówno polityk czasu rzeczywistego, jak i polityk opartych na zasobach. Limit czasu rzeczywistego obsługuje zawieszenia, procesy uśpione i zakleszczone programy. Rozliczanie CPU wykrywa obciążenia, które spalają moc obliczeniową bez postępu.

Nadzorca musi pozostawać poza gościem. Kod działający wewnątrz maszyny nie powinien kontrolować timera, sygnału zakończenia ani ostatecznej decyzji o sprzątaniu. W przeciwnym razie obciążenie może próbować wyłączyć własne zabezpieczenie.

Dlatego określenie „sandbox dla niezaufanego kodu” może ukrywać dwa odrębne produkty. Pierwszym jest silnik izolacji. Drugim — warstwa sterowania, która bezpiecznie planuje i nadzoruje ten silnik.

Test anthropic simon był ukierunkowany na zachowanie kompletnego produktu. Publiczny interfejs smolvm zapewnia przede wszystkim silnik izolacji oraz niskopoziomową konfigurację potrzebną do jego zbudowania.

MicroVM zmienia granicę, a nie model zagrożeń

Wirtualizacja sprzętowa poprawia izolację, lecz każda funkcja świadomie przekazana do gościa staje się częścią powierzchni ataku.

smolvm używa libkrun VMM do uruchamiania lekkich maszyn wirtualnych. Gość otrzymuje własne jądro, podczas gdy host zachowuje kontrolę nad wirtualnym sprzętem i udostępnionymi urządzeniami.

Ta konstrukcja odpowiada na główny problem związany z kontenerami. Kontenery izolują obciążenia za pomocą funkcji jądra, ale wrogie procesy nadal wchodzą w interakcje z tym samym jądrem hosta za pośrednictwem dozwolonych wywołań systemowych. Luka w jądrze może więc zagrozić granicy kontenera.

Systemy microVM przesuwają tę granicę na zewnątrz. Wrogi kod najpierw napotyka jądro gościa i urządzenia wirtualne. Dotarcie do hosta zwykle wymaga przekroczenia granicy monitora maszyny wirtualnej lub hiperwizora.

AWS opracował microVM Firecracker wokół podobnej zasady dla obciążeń serverless. Firecracker łączy wirtualizację KVM z celowo ograniczonym modelem urządzeń, ograniczając niepotrzebny emulowany sprzęt.

smolvm nie jest po prostu nakładką na Firecracker. Jego obecna dokumentacja opisuje backendy libkrun dla macOS, Linuxa i Windows. Mimo to oba podejścia umieszczają każde obciążenie za oddzielnym jądrem gościa.

To rozdzielenie ma znaczenie, gdy system AI autonomicznie pisze kod. Wygenerowany kod może zawierać przypadkowe destrukcyjne zachowania, ataki na zależności, próby wykrywania poświadczeń lub celowe ładunki skopiowane z niezaufanych danych.

Funkcja przekształcania danych wiąże się z takim samym ryzykiem nawet bez AI. Użytkownik może przesłać kod Python, który skanuje system plików, wielokrotnie tworzy procesy, alokuje pamięć aż do awarii lub próbuje nawiązać połączenia wychodzące.

JavaScript nie jest automatycznie bezpieczniejszy. Programy Node.js mogą odczytywać pliki, uruchamiać podprocesy, otwierać gniazda, ładować rozszerzenia natywne i wyczerpywać pamięć, gdy te możliwości pozostają dostępne.

Ograniczenia na poziomie języka często okazują się kruche, ponieważ biblioteki standardowe udostępniają szeroką funkcjonalność. Zależności przechodnie mogą także wprowadzać kod natywny lub nieoczekiwane ścieżki dostępu.

Pełny gość Linux umożliwia programistom uruchamianie zwykłych pakietów Python i Node.js bez przepisywania ich pod wyspecjalizowane środowisko uruchomieniowe. Ta zgodność jest jednym z powodów, dla których microVM pozostają atrakcyjne.

Kompromisem jest większe środowisko gościa. Usługa musi dostarczyć jądro, obraz środowiska uruchomieniowego, biblioteki i urządzenia wirtualne. Każdy utrzymywany komponent wpływa na aktualizowanie poprawek, odtwarzalność i zaufaną bazę obliczeniową.

Dokumentacja smolvm wymienia system operacyjny hosta, backend hiperwizora, libkrun, smolvm oraz konto hosta wywołujące proces jako zaufane komponenty. Kompromitacja w tych warstwach może osłabić obiecywaną granicę.

Dokumentacja ostrzega również przed jawnym przekazywaniem możliwości. Zamontowany katalog udostępnia swoją zawartość. Włączenie sieci rozszerza listę osiągalnych usług. Przekazanie agenta SSH pozwala procesom gościa żądać podpisów, dopóki gniazdo pozostaje dostępne.

Są to rozsądne funkcje dla maszyn deweloperskich. W usłudze obsługującej anonimowe lub wrogie zgłoszenia powinny one zwykle pozostać wyłączone.

Dostęp do GPU wymaga jeszcze większej ostrożności. smolvm obsługuje interfejsy wykorzystujące współdzielone zasoby GPU hosta lub procesy po stronie hosta. Dokumentacja wskazuje, że zdalnego dostępu do CUDA nie należy traktować jako wzmocnionej izolacji GPU dla wielu dzierżawców.

To ograniczenie nie wpływa na proste zadanie konwersji danych w Pythonie. Ilustruje jednak szerszą zasadę: funkcje zwiększające wygodę mogą przekraczać czystą granicę gościa, która czyni podstawową architekturę atrakcyjną.

W przypadku wrogich obciążeń najbezpieczniejszy profil jest celowo nudny. Bez sieci, bez przekazywanych poświadczeń, bez usług hosta, bez GPU, z minimalnymi wejściami tylko do odczytu i jednorazowym obszarem wyjściowym.

Maszyna wirtualna powinna zostać zniszczona po jednym zadaniu. Ponowne użycie maszyny grozi przeniesieniem zmodyfikowanych plików, procesów, pamięci podręcznych lub ukrytego stanu do wykonania kolejnego użytkownika.

Przenośne obrazy mogą pomóc w zapewnieniu spójnych środowisk wykonawczych. smolvm używa obrazów OCI, opartych na formacie obrazów OCI, dzięki czemu operatorzy mogą przygotowywać środowiska Python lub Node.js w znanym standardzie pakowania.

Zgodność obrazów nie oznacza zaufania do obrazów. Usługa produkcyjna nadal potrzebuje przypiętych skrótów, kontrolowanych rejestrów, obsługi podatności oraz procesu przebudowy środowisk po aktualizacjach bezpieczeństwa.

Limity zasobów wymagają czegoś więcej niż flag CPU i pamięci

Najtrudniejszą ochroną przed „while true” nie jest izolacja, lecz niezawodne zakończenie działania w każdym trybie awarii.

Ustawienie pamięci wyznacza gościowi górny limit widocznej pamięci RAM. Gdy program przekroczy tę pojemność, jądro gościa może uruchomić mechanizm braku pamięci. Ogranicza to jedną formę nadużycia zasobów.

Host nadal musi obserwować, co następuje później. Gość może zabić tylko jeden proces, przestać odpowiadać lub poświęcić dużo czasu na odzyskiwanie pamięci. Usługa nie może zakładać, że każda awaria pamięci da czysty rezultat.

Rygorystyczny uruchamiacz powinien klasyfikować wyniki. Sukces, wyjątek użytkownika, wyczerpanie pamięci, przekroczenie limitu czasu, przepełnienie danych wyjściowych, wewnętrzna awaria piaskownicy i odrzucenie z powodu pojemności hosta to różne zdarzenia.

Ta klasyfikacja ma znaczenie dla użytkowników i operatorów. Skrypt transformacji z nieprawidłową składnią nie powinien wyglądać jak awaria infrastruktury. Maszyna, której nie udało się uruchomić, nie powinna zużywać limitu ponownych prób użytkownika.

Limity CPU wymagają kilku warstw. Gość może otrzymać ograniczoną liczbę wirtualnych CPU. Kontrole hosta, takie jak cgroups, mogą następnie regulować proces VMM względem innych obciążeń.

Nadzorca terminów powinien zakończyć całą maszynę wirtualną po upływie dozwolonego czasu. Zabicie wyłącznie nadrzędnego procesu Python lub Node.js jest niewystarczające, ponieważ program może tworzyć procesy potomne lub działające w tle.

Kończenie działania musi też obejmować eskalację. Nadzorca może najpierw zażądać łagodnego zamknięcia, a następnie zatrzymać proces VMM, jeśli gość nie odpowie. Powinien zweryfikować, że powiązane procesy i zasoby tymczasowe zniknęły.

Dane wyjściowe są kolejnym zasobem. Program może drukować bez końca, tworzyć ogromne pliki wynikowe lub generować głęboko zagnieżdżone dane, które po zakończeniu wykonania zużywają pamięć parsera.

Usługa potrzebuje limitów bajtowych dla standardowego wyjścia, standardowego błędu i generowanych plików. Powinna strumieniować lub obcinać logi bez buforowania nieograniczonej zawartości w pamięci aplikacji.

Limity przestrzeni dyskowej powinny obejmować zapisywalną warstwę gościa i każdy eksportowany katalog wyjściowy. W przeciwnym razie niewielkie dane wejściowe mogą wytworzyć dość danych, by zapełnić system plików hosta.

Znaczenie ma też liczba procesów. Bomba fork tworzy procesy szybciej, niż może zareagować człowiek-operator. Jądro gościa potrzebuje limitów procesów, a host powinien ograniczać VMM i jego procesy pomocnicze.

Wrogi program może również wykorzystywać czas bez pełnego obciążania CPU. Może spać w nieskończoność, czekać na brakujące dane wejściowe lub tworzyć zakleszczenie. Dlatego limity czasu zegarowego pozostają obowiązkowe.

Czas powinien być mierzony przez zewnętrzną płaszczyznę sterowania. Gość może zmienić własny zegar lub zakłócić wewnętrzne procesy nadzorujące. Monotoniczny zegar hosta zapewnia bardziej wiarygodne źródło.

Eksport plików musi następować dopiero po zakończeniu wykonania. Host powinien sprawdzić typy, rozmiary, ścieżki i liczbę plików przed przeniesieniem wyników do trwałego magazynu.

W przypadku typowych transformacji danych węższy kontrakt wyjściowy może ograniczyć ryzyko. Uruchamiacz może przyjmować jeden dokument JSON, jeden plik CSV lub archiwum o ograniczonym rozmiarze zamiast dowolnego drzewa katalogów.

Usługa powinna również ograniczać złożoność danych wejściowych przed uruchomieniem maszyny. Skompresowane archiwa mogą rozwinąć się znacznie ponad swój rozmiar po przesłaniu, a złośliwe formaty mogą atakować parsery poza gościem.

Bezpieczna sekwencja zaczyna się więc przed smolvm. Waliduj i przygotowuj dane wejściowe, twórz świeżą maszynę, egzekwuj limity czasu działania, zatrzymuj maszynę, sprawdzaj dane wyjściowe, a następnie niszcz stan tymczasowy.

Obserwowalność również należy umieścić poza gościem. Operatorzy potrzebują identyfikatorów maszyn, skrótów obrazów, czasów uruchomienia i zatrzymania, klasyfikacji zakończeń, szczytowego wykorzystania zasobów oraz stanu czyszczenia.

Te rekordy powinny domyślnie unikać przechowywania wrażliwych danych użytkowników. Logi mogą stać się kolejnym kanałem wycieku, gdy skrypty wypisują rekordy wejściowe, poświadczenia lub treści zastrzeżone.

Żaden z tych wymogów nie podważa wartości smolvm. Określają one otaczającą pracę potrzebną do przekształcenia jego niskopoziomowych prymitywów w niezawodną usługę.

Docker, WebAssembly i hostowane piaskownice nadal konkurują

smolvm zajmuje użyteczną pozycję pośrednią, oferując zwykłą kompatybilność z Linuksem przy silniejszym rozdzieleniu niż kontener ze współdzielonym jądrem.

Docker pozostaje najłatwiejszym punktem wyjścia dla wielu zespołów inżynieryjnych. Obrazy, rejestry, narzędzia budowania i systemy orkiestracji już obsługują przepływy pracy kontenerów na dużą skalę.

Kontenery mogą stosować przestrzenie nazw, capabilities, filtry seccomp, systemy plików tylko do odczytu i limity cgroup. Te mechanizmy kontroli mogą być odpowiednie, gdy obciążenia są zaufane lub tylko umiarkowanie ryzykowne.

Współdzielone jądro pozostaje główną obawą w przypadku w pełni wrogiego kodu. Luka umożliwiająca ucieczkę w jądrze hosta lub środowisku uruchomieniowym kontenerów może ujawnić inne obciążenia i dane hosta.

smolvm zmienia ten poziom ekspozycji, przypisując każdej maszynie oddzielne jądro gościa. Przyjmuje też obrazy OCI, zmniejszając część tarcia migracyjnego dla zespołów z istniejącymi środowiskami Python lub Node.js.

Platformy kontenerowe mają jednak dojrzałe warstwy harmonogramowania i polityk. Dokumentacja bezpieczeństwa smolvm stwierdza, że samodzielne narzędzie nie jest samo w sobie wzmocnioną płaszczyzną sterowania dla wielu użytkowników.

Zespół zastępujący kontenery smolvm musi unikać utraty zabezpieczeń operacyjnych podczas migracji. Silniejsza izolacja pod słabszym harmonogramem nadal może prowadzić do zawodnej usługi.

WebAssembly podąża inną drogą. Środowisko wykonawcze WebAssembly zaczyna od ograniczonego modelu uprawnień, a następnie jawnie przyznaje funkcje, takie jak dostęp do plików lub sieci.

Takie podejście może tworzyć mniejszy interfejs dla niewielkich obciążeń transformacyjnych. Obsługuje też szybkie uruchamianie i precyzyjne osadzanie w aplikacji.

Kompromisem jest kompatybilność. Standardowe pakiety Python i Node.js mogą oczekiwać wywołań systemowych Linux, rozszerzeń natywnych, podprocesów lub zachowań środowiska wykonawczego niedostępnych w ograniczonym środowisku WebAssembly.

Zespół kontrolujący język transformacji może zaakceptować te ograniczenia. Usługa obiecująca szeroką kompatybilność z Pythonem i JavaScriptem szybko się z nimi zetknie.

Hostowane piaskownice kodu oferują trzecią drogę. Dostawcy pakują cykl życia maszyn, limity czasu, politykę sieciową, magazynowanie i API w zarządzane usługi.

Może to skrócić czas wdrożenia. Przenosi jednak wrażliwy kod i dane do innego operatora, wprowadza zależności od usługi i ogranicza kontrolę nad bazowym projektem izolacji.

Samodzielne hostowanie smolvm utrzymuje środowisko wykonawcze pod administracją nabywcy. Czyni też nabywcę odpowiedzialnym za utwardzanie hosta, aktualizacje bezpieczeństwa, planowanie pojemności, monitorowanie i reagowanie na incydenty.

Wybór powinien wynikać z obciążenia, a nie z mody. Ograniczony ewaluator wyrażeń nie potrzebuje kompletnego gościa Linux. Złożony pakiet Python z zależnościami natywnymi prawdopodobnie go potrzebuje.

W przypadku jednorazowych transformacji uruchamianie microVM musi pozostać krótkie w stosunku do czasu trwania zadania. smolvm podaje, że spakowane obciążenia mogą uruchamiać się w mniej niż 200 milisekund, lecz niezależne pomiary powinny obejmować dokładne hosty i obrazy nabywcy.

Benchmarki powinny uwzględniać pobieranie zimnego obrazu, tworzenie maszyny, uruchamianie środowiska wykonawczego, przygotowanie danych wejściowych, wykonanie, walidację wyników i zniszczenie. Mierzenie wyłącznie czasu rozruchu gościa zaniża opóźnienie widoczne dla użytkownika.

Zespoły powinny również testować gęstość. Jeden szybki gość niewiele mówi o hoście obsługującym setki jednoczesnych zgłoszeń pod presją pamięci.

Pytanie konkurencyjne jest więc szersze niż siła izolacji. Obejmuje kompatybilność, zachowanie przy uruchamianiu, dojrzałość harmonogramowania, obciążenie operacyjne i konsekwencje udanej ucieczki.

smolvm zasługuje na ocenę, ponieważ łączy znane obciążenia Linux z granicą VM. Próba anthropic simon pokazuje, że taka ocena musi odbywać się na infrastrukturze zdolnej ujawnić wymagane funkcje wirtualizacji.

Trzy testy zdecydują, czy smolvm jest gotowy

Kolejne użyteczne dowody muszą pochodzić z testów wrogich obciążeń, a nie z kolejnej listy funkcji.

Pierwszym sygnałem jest odtwarzalny test na zgodnym hoście bare-metal lub z zagnieżdżoną wirtualizacją. Powinien uruchamiać zestawy testów Python i JavaScript przez tego samego zewnętrznego nadzorcę.

Zestawy te powinny obejmować nieskończone pętle, wyczerpanie pamięci, bomby fork, nadmierne dane wyjściowe, próby badania systemu plików, próby sieciowe, opóźnione procesy potomne i nietypowe zamknięcia gościa. Każdy przypadek wymaga oczekiwanego wyniku.

Pomyślny rezultat wzmocniłby argument, że smolvm może służyć jako mechanizm izolacji dla zadań transformacyjnych. Powtarzające się błędy czyszczenia lub niespójne kończenie działania osłabiłyby go.

Drugim sygnałem jest jawne, udokumentowane egzekwowanie cyklu życia. Referencyjny uruchamiacz powinien pokazywać, jak narzucać limity czasu zegarowego, kontrole CPU na poziomie hosta, limity pamięci, limity danych wyjściowych i całkowite niszczenie maszyny.

Flagi konfiguracyjne nie wystarczą. Test powinien weryfikować zachowanie, gdy gość ignoruje żądania zamknięcia, zapełnia magazyn i pozostawia procesy potomne.

Ten sygnał zamknąłby lukę między prymitywami VM smolvm a usługą, którą Willison pierwotnie chciał zbadać. Bez niego każdy wdrażający musi niezależnie projektować krytycznego nadzorcę.

Trzecim sygnałem jest przegląd bezpieczeństwa w ramach zadeklarowanego modelu zagrożeń. Przegląd powinien określić zaufane komponenty hosta, zachowanie montowanych plików, egzekwowanie sieci, pochodzenie obrazów i założenia dotyczące wielu dzierżawców.

Istniejąca dokumentacja smolvm już zawiera użyteczne ujawnienia. Podaje, że wydania obecnie nie mają podpisów ani poświadczeń pochodzenia, choć weryfikacja sum kontrolnych jest dostępna, gdy można pobrać plik sum kontrolnych.

To ujawnienie daje oceniającym konkretne pytanie dotyczące łańcucha dostaw. Operator produkcyjny potrzebuje kontrolowanej metody pozyskiwania, weryfikowania, przypinania i aktualizowania binarnego pliku smolvm oraz obrazów gościa.

Ocena powinna też rozróżniać lokalne wykonanie przez jednego użytkownika od wrogiego środowiska wielodzierżawnego. Deweloper uruchamiający wygenerowany kod na laptopie ponosi inne konsekwencje niż publiczna usługa przyjmująca anonimowe zgłoszenia.

Żadna piaskownica nie może zmienić dowolnego kodu w obciążenie wolne od ryzyka. Praktycznym celem jest wielowarstwowe ograniczanie, kontrolowane uprawnienia, ograniczone zużycie zasobów i szybkie odzyskiwanie sprawności, gdy jedna warstwa zawiedzie.

Najbardziej obiecujący wzorzec wdrożenia wykorzystuje smolvm jako jedną warstwę tego systemu. Usługa hosta waliduje dane wejściowe, tworzy jednorazowego gościa, wstrzymuje dostęp do sieci, egzekwuje limity czasu, sprawdza dane wyjściowe i niszczy środowisko.

Dla zespołów budujących przepływy pracy oparte na AI wniosek wykracza poza wykonywanie kodu. Każdy system, który pozwala modelowi działać na lokalnych informacjach, potrzebuje wyraźnych granic określających, co model może odczytywać, zapisywać i przechowywać.

Przeszukiwalna baza wiedzy może pomóc inżynierom zachowywać wyniki testów, modele zagrożeń i ustalenia z incydentów. Nie zastąpi izolacji środowiska uruchomieniowego, ale może ułatwić audytowanie decyzji dotyczących bezpieczeństwa.

Eksperyment anthropic simon należy więc traktować jako niedokończoną ocenę z użytecznym pierwszym ustaleniem. smolvm nie mógł działać w wybranym środowisku Claude Code, ponieważ zewnętrzny sandbox nie udostępniał dostępu do wirtualizacji.

Kolejnym krokiem nie jest poluzowanie tego zewnętrznego sandboxa. Należy powtórzyć ocenę na dedykowanym, kompatybilnym hoście z zewnętrznym mechanizmem nadzorującym oraz opublikowanym zestawem testów adwersarialnych.

Czy Twoja usługa nadal zatrzymałaby każde zadanie, zachowała wyłącznie zatwierdzone wyniki i całkowicie posprzątała po sobie, gdy środowisko gościa stanie się wrogie? Jeśli tego nie zmierzono, sandbox nie jest gotowy na kod użytkownika.