Microsoft toont besturingssysteem Litebox als alternatief voor VM's

Microsoft heeft een lichtgewicht besturingssysteem uitgebracht waarmee Linux-applicaties in een sandbox kunnen draaien. Litebox is volledig in Rust geschreven en beschikbaar onder een MIT-licentie. Het OS is bedoeld als alternatief voor VM's, maar dan een waarbij de kernel bijvoorbeeld niet gedeeld wordt.

Litebox is een project dat Microsoft op GitHub heeft gezet. Microsoft noemt het 'een librarybesturingssysteem voor sandboxing', dat 'de interface naar de host drastisch reduceert'. In de praktijk is Litebox een laag tussen twee secties van het besturingssysteem, wat Microsoft de 'north- en southinterface' noemt. Die ene bestaat uit shims, die api's gebruiken om functies uit te voeren in het platform, zoals Linux of Windows, of juist de Linux-kernel.

Volgens Microsoft is het besturingssysteem bedoeld voor verschillende soorten toepassingen. Zo kan het worden gebruikt om onaangepaste Linux-software op Windows draaien, maar ook gesandboxte Linux-applicaties op Linux. Ook kunnen gebruikers zo programma's boven op een beveiligingssysteem zoals SEV-SNP draaien.

In de praktijk kan het besturingssysteem worden gebruikt voor applicaties waarbij het niet mogelijk of verstandig is om een kernel te delen. Litebox kan dan dienen als een alternatieve kernel. De software is volledig in Rust geschreven, wat geheugenkwetsbaarheden moet voorkomen. Het OS is beschikbaar onder een MIT-licentie, zegt Microsoft.

Reacties (35)

[smartbit]

heise probeert een eerste aanzet te maken tot vergelijking met andere producten

Compared to alternatives such as gVisor from Google, which intercepts system calls in user space, or Firecracker from Amazon, which uses Rust-based micro-VMs, LiteBox promises particularly low overhead through its library OS architecture. However, concrete performance benchmarks are not yet available. Kata Containers, which provides VMs for Kubernetes, addresses similar use cases but relies on a different technical basis.

Hier een talk waarin Linux Virtualization Based Security (LVBS) wordt uitgelegd door Thara Gopinath, Principal Software Engineering Lead at Microsoft

This talk introduces the concept of Linux Virtualization Based Security (LVBS) as an umbrella term for various hypervisor-backed kernel protection solutions. LVBS implements a common, hypervisor-agnostic, and extendable architecture in the Linux kernel that should allow any hypervisor to implement and expand upon Linux kernel protections. This architecture enables different hypervisor frameworks-Hyper-V, as an example of a type-1 hypervisor, and KVM, as an example of a type-2 hypervisor-to connect with the common layer and enhance Linux kernel security.

The discussion then addresses ongoing efforts to implement the proposed architecture, focusing on several key areas:

• History, development and status of the hypervisor-agnostic common layer
• Utilization of Hyper-V’s Virtual Secure Mode (VSM) in combination with the common layer to reinforce Linux kernel protection, including current progress
• Application of the proposed architecture by KVM and the current development status

[Pinkys Brain]

Het zit het meest dicht bij V8 Isolates en Hyperlight-wasm. Taal en bibliotheek gebaseerde isolatie, alleen nu met native code dankzij Rust.

[Umbrah]

Dat moet je even uitleggen. Relateer je aan de Tanenbaum/Torvalds discussie over monlitische/microkernel ontwerpen? Torvalds (Linus) was heel erg "pro" monolieten, waarbij alles in een groot blok draaide, wat als voordelen had dat alles op een plek stond, wat veel efficiëntie kon veroorzaken. Dat had als nadeel dat één rotte appel de hele kernel kon crashen (zoals een driver...). Het is nu echter 2026 en Linux is al lang niet meer een stricte monoliet, en kan modules/drivers in de vorm van LKM's vrij dynamisch laden/onladen; Linux is dus een hybride geworden.

Tanenbaum/minix had een heel andere visie, waarbij de kernel 100% modulair was, en dat alles tot memory management aan toe geladen/ontladen kon worden, met een stricte scheiding tussen kernel en user processen. Meer isolatie (goh gezien hoeveel sandboxes en containerisatie we nu hebben op linux...). Nadeel was wel dat alles wat trager was. Veel moderne microkernel systemen (L4, BSD, etc...) zijn tegenwoordig ook hybride.

Windows was dat ook al vrij lang, met een vrij duidelijke HAL (Hardware Abstraction Layer) die modulair was voor bepaalde drivers/tools, en andere dingen vrij dynamisch in userspace kon draaien. Ook daar zit evolutie in, zoals recentelijk rondom security/virusscanners (waar redelijk wat abuse in zat.

Momenteel is eigenlijk elke kernel (Linux, BSD, Windows, MacOS) eigenlijk gewoon hybride, en zit er qua model zelfs een beetje een soort van convergente evolutie in. Wat verdraaid lastig is, want veel systemen hebben een enorme legacy omhoog te houden... denk bij die legacy ook aan 'dependency hell', waarbij sommige OS-en niet in staat zijn om twee libraries met dezelfde filename in geheugen te houden (denk aan iets als Open3D... waar VEEL variatie in versies zit), waardoor "on metal on kernel" erg lastig is in sommige takken van ontwikkeling, waardoor zaken als containerisatie eigenlijk die hele kernel an-sich weer minder relevant maken...

Eigenlijk, in relatie tot deze nieuwe architectuur van Microsoft, vind ik dat wel weer een heel mooie circulaire stroming naar dit model van modulair... denk dat dit naar userland brengen voor de "android ipad windows linux macos" gebruiker misschien niet snel gebruikt, want laat ik eerlijk zijn: hoe lullig ik het ook vind, de eindgebruiker heeft als kernwens eigenlijk alleen maar "draai chromium render geglorificeerde html/js" als eis tegenwoordig... op een smaak gebruikers (tweakers, devs, etc...) na.

[NaioN]

Ik zou hem even wat willen aanscherpen, het gaat er namelijk niet zozeer om om een driver (of welk ander component in de kernel dan ook) dynamisch / als module in- of uitgeladen kan worden, maar het gaat erom in welke protectie laag (ring) het betreffende component of de driver draait op de CPU.

Bij Micro Kernels draait er een kleine kernel die voornamelijk voor inter-kernel-component-communicate en de daadwerkelijke toegang tot de hardware in ring 0 op de CPU en draaien alle andere drivers en componenten van de kernel op een hogere ring (afhankelijk van de architectuur heb je meestal 2 tot 4 niveaus, waarbij de laagste ring de meeste toegang biedt en de hoogste ring de minste toegang biedt).

Bij Monolitische Kernels draaien in principe alle drivers en kernel componenten in ring 0, ongeacht of de dynamisch in- of uitgeladen kunnen worden.

Ik ben het overigens met je eens dat we tegenwoordig steeds meer een hybride kernel zien, waarbij een aantal kernel taken worden uitgevoerd door userland processen.

Ik kan me overigens nog herinneren dat in de eerste Windows NT (3.x) versies de videodriver in userland draaide en dat daarmee de NT kernel wat meer richting een microkernel ging, dat hebben ze echter later weer terug in ring 0 gebracht wegens performance uitdagingen.

Volgens mij is QNX een van de weinige echte Micro Kernels, waarbij zo goed als alle componenten in userspace draaien. Bij de meeste andere zie je toch vaak dat belangrijke zaken als process, schedule, memory, etc management in ring 0 draaien.

Dus wat dat betreft ben ik van mening dat de meeste kernels tegenwoordig toch nog steeds meer monolitisch dan micro zijn, waaronder ook die van Linux en Windows.

[VirtualGuineaPig]

Zinnige reacties. Dank. En duidelijk dat er nog lang geen einde is aan de ontwikkelingen van welk OS dan ook.

Maar blijft mijn vraag of het niet zinnig is als Microsoft gewoon eens een heel goede , snelle en bruikbare omgeving zou maken die op elk OS kan draaien waarmee win programmatuur portable wordt.

En ja, ik weet ook dat die slag al deels gedaan is met het porten naar ARM en de HAL.En ja, de W11 ntoskrnl is hybride maar feit is dat veel bovenliggende processen nog steeds ring0 toegang moeten/willen hebben.

Wat betreft de Kathedraal/Kashba discussie: ik neig toch naar de Kashba omdat m.i. daarmee meer gelijkwaardigheid te bereiken is.

(OT ik begin meer en meer twijfels te krijgen over de moderatie in dit forum. Mijn opmerking maakt een uiterst interessante en zinnige discussie los en toch wordt mijn initiële post op -1 gezet. So be it)

[Reactie gewijzigd door VirtualGuineaPig op 6 februari 2026 13:42]

[beerse]

Volgens mij is het net de andere kant op. Waar het tussen Tanenbaum en Trovalds ging om een betrekkelijk eenvoudige kernel dan nog weer verder ophakken in onderdelen. Daar tegenover is msWindows en dan met name wnt juist helemaal de andere kan top: zo veel mogelijk functionaliteit er in frutten om er zo veel mogelijk uit te halen.

[DrPoncho]

monolytisch

Waarom is dit negatief?

inherent onveilig

Hoezo inherent?

[NaioN]

Omdat veel meer code in ring 0 draait en meer code bevat meer bugs, dus is er een grotere kans dat er een bug zit in de code die in ring 0 draait en daarmee dus ook direct veel gevaarlijker is.

Zie mijn reactie hierboven.

Overigens kun je makkelijk een hybride kernel hebben die nog onveiliger kan zijn, het is maar net welke componenten en hoeveel code is op ring 0 laat draaien.

Bij een microkernel is het over het algemeen lastiger, aangezien je alleen met het component dat in ring 0 draait kunt communiceren via APIs en het betreffende component vaak heel klein is, aangezien het weinig functies hoeft te bevatten (inter-kernel-component-communicatie en toegang tot hardware op een abstracte wijze)

Maargoed zover zien we het in de praktijk niet doorgevoerd, aangezien een microkernel ook wat nadelen heeft, zeker op het gebied van performance.

[bzuidgeest]

Je linux kernel is een monolitisch design. En veilig is linux alleen vanwege de mindere aandacht en obscurity. En zelfs dan is de lijst van kernel (en userland) vulnerabilities niet echt kort te noemen.

Als je een argument wil maken dat linux beter is, dan kan je gewoon open versus closed noemen.
Maar ga niet jou soort verouderde en incorrecte argumenten lopen roepen.

[NaioN]

Ik vind dit eerlijk gezegd een vreemde redenatie.

De Linux kernel draait op vele malen meer computers/apparaten dan welke andere kernel dan ook. Daarnaast is er geen obscurity, aangezien de code opensource is, dus voor iedereen inzichtelijk.

Ik denk wel dat de wijze van ontwikkelen heeft bijgedragen aan de veiligheid van de Linux kernel.

[bzuidgeest]

Ik vind het een vreemde reactie. De kernel draait inderdaad op veel hardware, maar dat maakt het nog steeds een monolithisch design en geen bijvoorbeeld microkernel design als minix. als je niet bekend bent met die termen verwijs ik je naar wikipedia. Het heeft niets te maken met op hoeveel soorten hardware iets draait.


En obscurity is een term voor "zeldzaamheid" Voor de desktop is linux in vergelijking met windows nog steeds obscure (weinig gebruikt) Dus is het voor hackers en social engineers en andere dieven een minder aantrekkelijk platform om te "ondersteunen", ofwel om achter aan te gaan.
Ook dit heeft niets te maken met of de code open is. Het heeft te maken met hoe vaak de code word ingezet. Er is natuurlijk de wereld van embedded linux, maar je kan een sluis of koelkast geen geld af troggelen.

Er is overigens een argument dat wel gemaakt word dat open code onveiliger is omdat iedereen gemakkelijker issues om te exploiten kan vinden. Echter ik denk zelf dat dit offset word doordat er ook meer mensen aan werken om ze te fixen. En dat iedereen ze kan fixen.

[NaioN]

Ik vond het juist vreemd dat je Linux veilig verklaarde wegens minder aandacht en obscurity, vandaar dat ik verwees naar het vele gebruik van de Linux kernel en het feit dat het opensource is.

Gezien het op veel meer en veel meer soorten apparaten draait is het juist een veel gewilder doelwit, het alleen naar computer servers en desktops kijken is daarbij juist beperkend. Het is wellicht de meest zichtbare voor de meeste mensen en ook hetgeen waar de mensen zelf vaak directer mee te maken hebben, maar dat laat onverlet dat de Linux kernel op veel meer plekken in gebruik is en dat dat voor bepaalde (wellicht minder zichtbare) groepen hackers veel interessanter is. Ik zou het dan ook wat anders willen formuleren, bij Windows is het gewoon heel makkelijk om er geld aan te verdienen als reguliere/criminele hackers groep want vaak kun je met weinig effort toch veel binnen halen.

Om obscurity een term voor "zeldzaamheid" te gebruiken is nog vreemder, aangezien vaak de term al in combinatie wordt gebruikt met "security by obscurity" en dat slaat juist (deels) op het niet kunnen inzien van de broncode.

Ik ben het overigens wel met je laatste deel eens, dat open source een voor- en nadeel heeft voor security in de zin dat het makkelijker zoeken is naar bugs en exploits, maar dat dat weer tegengewerkt wordt door het feit dat ook meer mensen kunnen kijken en fixen. Overigens was het ook deels daarnaar waar ik verwees met ontwikkelproces dat mijn inziens beter is.

[bzuidgeest]

met "security by obscurity" en dat slaat juist (deels) op het niet kunnen inzien van de broncode.

Dat is een veel te smalle interpretatie. Misschien zelfs een verkeerde. Het wel of niet kunnen zien is een factor, maar zeker niet de belangrijkste. Het duid meer op er van uitgaan dat niemand de moeite neemt te kijken. Of niemand het weet te vinden. En ja een gedeelte van de veiligheid van Linux ontstaat doordat het economisch een minder aantrekkelijk doel is. Een koelkast aanvallen heeft gewoon geen zin.

Voor jou:

In the context of rarity,

obscurity refers to the state of being unknown, inconspicuous, or forgotten by the general public. It signifies that something or someone is not well-recognized, prominent, or famous, often implying that they are hidden away or exists in the "shadows"

Ik denk dat een engelsman je ongelijk geeft met je opinie dat mijn gebruik "raar" is.

[NaioN]

Ik denk dat we er niet gaan uitkomen, maar goed zegt denk ik genoeg dat je alleen nog op het woord obscurity ingaat, waarbij je zelf al aangeeft dat je het in de context van rarity plaats, maar obscurity meerdere betekennissen heeft (zoals je zelf ook al aangeeft) dan dat en ook binnen de term "security by obscurity" een veel bredere context geplaatst dient te worden, waaronder zowel de mijne als de jouwe interpretatie vallen, vandaar dat ik ook deels aangaf.

[bzuidgeest]

Alleen laat ik het veel breder vallen en ik noem de overige betekenissen die jij negeert niet gek.

[Miglow]

Hoeven we hiermee niet meer een XUbuntu VM te draaien om een bepaalde Linux server of Home Assistant te draaien?

[Reactie gewijzigd door Miglow op 6 februari 2026 10:34]

[goarilla]

Misschien, maar je gaat wellicht vaak als nog niemand anders het gedaan heeft, het in elkaar
moeten kloppen, schapen om het te doen werken voor deze "container/unikernel/VM hybride
oplossing" . En dat kan weleens moeilijk worden. VM's zullen wellicht voor vele toepassingen
nog altijd makkelijker zijn. Je hebt er wellicht al deploy scripts/tools/whatever voor.

[beerse]

Zoals ik de omschrijving in het bericht hier boven lees, denk ik dat deze 'litebox' de tegenhanger is van 'wine' onder linux: Met litebox zou je een linux applicatie onder msWindows zo moeten kunnen draaien.

Net zoals de ontwikkeling van wine onder linux is gegaan: in het begin waren er een paar applicaties die wel werkten. Dat zijn er steeds meer geworden. Ondertussen is wine zo ver dat het vooral microsoft applicaties zijn die niet goed werken omdat die applicaties gebruik maken van mswindows-systemcalls die niet publiek bekend zijn. Hoe dat met litebox gaat gebeuren valt te bezien. Om vanaf een mswindows machine een linux applicatie te draaien zijn er ondertussen meer routes die al wel bewezen zijn.

Misschien is deze litebox voort gekomen uit microsofts eigen keuken waarbij ze zelf opensource applicaties onder mswindows beschikbaar maken.

[toegevoegd] de methodes om linux apps onder mswindows beschikbaar te krijgen zijn onderandere: cygwin, al vergt dat hercompileren en zo. Windows-subsystem-for-linux (wsl), in versie 1 en 2, net geen volledige virtuele machine. Of virtuele machines in diverse smaken: VMware, VirutalBox of hyper-v en dergelijke. Of een echte linux installatie op een voor msWindows afgeschreven machine.

[Reactie gewijzigd door beerse op 6 februari 2026 10:55]

[GertMenkel]

Als je op Windows zit, kun je met WSL2 gewoon normale docker-containers draaien voor dat soort dingen.

Deze aanpak is soortgelijk aan die van het originele WSL, alhoewel het originele WSL in de NT kernel draaide en dit volledig in usermode. Ze zijn met die aanpak gestopt om performanceredenen, om complexiteitsredenen, en omdat hun eigen kernel shims een hele hoop compitabiliteitsissues veroorzaakte die ze continu zaten op te lossen.

Aangezien WSL1 niet eens een succes was, betwijfel ik dat dit de "Wine voor Linux" zal zijn die het in theorie kan worden. Het lijkt me eerder een sandboxmethode voor (malware) research, het toevoegen van security boundaries, en voor compitabiliteitshacks.

[japie06]

Moet ik dit zien als Microsofts antwoord op docker/containers in Windows?

[JBuijs91]

Ik vind de beschrijving heel erg lijken op LXC containers in Linux (zoals je in Proxmox bijvoorbeeld hebt)

[devilkin]

Daar doet het me ook aan denken.

[downtime]

Daar heeft Microsoft allang Windows Nano Server voor.

[rjmno1]

ja maar dat is beter dat als je een harde schijf formatteerd voor linux die daarna niet meer windows kan maken want dat heb ik nu ik had linux mint erop.en ik kan de schijf niet meer terug heroepen waar dat aanlicht dat weet ik niet ik heb al alles geprobeert.Die had ik ext4 geformatteerd.

[Reactie gewijzigd door rjmno1 op 6 februari 2026 12:59]

[jvwou123]

@TijsZonderH handig: hoef je je Windows PC niet meer helemaal te herstarten voor het
[code]sudo geef geld[/code]
grapje

edit:
werkt [code] niet meer?

[Reactie gewijzigd door jvwou123 op 6 februari 2026 10:46]

[treris]

Dat is een mooi praktisch voorbeeld ja.

[hottestbrain]

Werkte dat niet ook met de windows sudo implementatie? Lijkt me nou net het eerste praktijkvoorbeeld waar microsoft compatibiliteit mee zou willen garanderen.

[i-chat]

als ik die diagram zo zie dan lijkt dit sterk op een kruising tussen docker en wine. maar wat het nou echt is ontgaat me volledig.

[Z80]

En het een OS noemen? Ik kan er geen OS is zien. Zie ik iets over het hoofd? En zo ja hoe maak je dit systeem bootable.

[bullseye1977]

SteamOS/Bazzite boven op je Windows

[goarilla]

En zo wordt ieder OS "InceptionOS".
Turtels op turtels op turtels ...

[Pinkys Brain]

Is dit Rust taal gebaseerde isolatie? (zie Isolation in Rust: What is Missing?) Of draait alles onder wasm?

Zo te zien toch gecompileerd naar native code, ik dacht eerst wasm.

[Reactie gewijzigd door Pinkys Brain op 6 februari 2026 11:56]

[davekok]

Maar uh, wat doet het nu doen. Een soort interpreter voor een Linux binary? Of een echte virtualisatie? Of een ding dat on-the-fly syscalls afvangt en omkat naar iets anders?

[SilentDecode]

"Lichtgewicht" en "Microsoft" in 1 zin? Klopt dat wel?