Connexion
Vous avez envie de voir à quoi ressemble Googlebook OS , mais pas du tout envie de dégainer +1000 balles pour un ordi bridé ? Ça tombe bien, un développeur a codé gbos-vm , un outil open source sous licence MIT qui lance sur un Mac Apple Silicon l'image de recovery de Google (conçu à l'origine pour le Dell Googlebook), dans une machine virtuelle boostée par le GPU.
Ce n'est donc pas un Android générique habillé en Googlebook mais un script qui télécharge l'image officielle (la build 16471258, ARM64, Android 17), en vérifiant l'empreinte, puis la fait démarrer sous QEMU avec Vulkan traduit vers Metal. Et rien de chez Google n'est redistribué dans le dépôt (pas de Playstore de base donc...).
Côté Mac, il vous faut donc un Mac avec archi Silicon, Homebrew, les outils en ligne de commande de Xcode, un JDK et le SDK Android (plateforme API 34 minimum) avec son NDK. Et comptez 16 Go de RAM en pratique car la VM en squatte 4 mais les compilations successives en auront besoin d'un peu plus. Et le script installera de lui-même tout ce qui vous manquera côté Homebrew, sans jamais vous demander un accès via sudo. Comptez environ 9 Go pour le download de tout ça et minimum 60 Go de libre pour la VM.
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) git clone https://github.com/skylartaylor/gbos-vm.git
cd gbos-vm
./install.sh
Ensuite, vous ouvrez l'application construite (dispo dans work/host/Googlebook VM.app), dont la mission est de lancer la VM et de l'éteindre proprement quand vous la quittez.
Le premier boot prendra environ 45 secondes sur un MacBook M5 et si un sélecteur d'utilisateur s'affiche, cliquez juste sur "User" et y'a pas de mot de passe. Notez que la souris est capturée par défaut, et que le raccourci ⌃⌥ la libèrera.
Voilà, c'est pas encore parfait car le bluetooth peut crasher, on est limité à 60 images par seconde max et que les échanges entre la VM et l'hôte (le mac) sont un peu instables mais j'imagine que tout ceci se bonifiera avec le temps...
Virtual Mac on iPad est un super projet sous licence libre qui permet de booter un bon vieux macOS dans une machine virtuelle sur... un iPad jailbreaké ! Hé ouais ! Les versions de Monterey à Tahoe sont prises en charge (la 27 étant encore bien bien expérimentale), et vous pouvez ainsi lancer Xcode, le Terminal ou Final Cut Pro, Logic Pro et Pixelmator Pro directement sur votre tablette Apple.
Côté matos, il faut un iPad Pro M1 ou M2, ou un iPad Air M1 (et ça fonctionne aussi semble-t-il sur les iPhone 14 Pro et 14 Pro Max). Les modèles de 1 To et 2 To, qui embarquent 16 Go de mémoire, sont ceux que les développeurs recommandent et niveau perf apparemment, on est au même niveau que ce qu'on peut obtenir avec VirtualBuddy ou UTM quand ils virtualisent macOS sur un Mac M1 ou M2.
Pour l'installer, faudra donc jailbreaker l'iPad (avec Dopamine par exemple), puis ajouter dans Sileo le dépôt du projet, dont voici l'adresse et y rechercher l'app Virtual Mac.
https://nfzerox.github.io/cydia/
Tout le process de jailbreak est décrit dans le readme du projet soit pour iPadOS 15 à 16.3.1 ou pour iPadOS 14 à 14.8.1. Par contre, la variante Dopamine-roothide n'est pas supportée, du coup faudra repasser sur le Dopamine officiel.
Côté utilisation, avoir un Magic Keyboard n'est pas obligatoire puisque le tactile suffit avec un tap pour cliquer, un tap à 2 doigts pour le clic secondaire et le défilement, sans oublier le clavier virtuel sous l'icône du clavier. En revanche, la connexion à iCloud ou à un compte Apple n'est pas prise en charge, donc pendant la configuration de macOS faudra choisir "Configurer plus tard" et vous vous en passez...
Maintenant ce projet exige iPadOS 16.3.1 au maximum, parce qu'Apple a retiré dès iPadOS 16.4, son hyperviseur du noyau. Et sans lui malheureusement, le portage vers les versions ultérieures est devenu très compliqué. Voilà donc cette bidouille de Virtual Mac sur iPad c'est avant tout un petit kiff technique réservé aux possesseurs d'iPad resté sur la 16.3.1 ou inférieur, car downgrader semble compliqué pour pas dire impossible.
Maintenant je tiens à vous rappeler que UTM SE tourne sur iPad sans jailbreak, mais n'a pas de JIT ce qui fait qu'il doit passer par un interpréteur donc c'est beaucoup plus lent. Ça sert donc surtout à faire tourner des systèmes + anciens ou allégés comme DOS ou Alpine Linux.
Bref, avant de jailbreaker quoi que ce soit comme des petits fifous, regardez bien dans les Réglages quelle version d'iPadOS tourne sur votre iPad pour voir si c'est jouable !
Source : Tom Dörr sur X
Windows 11 dans une machine virtuelle sur un Mac Apple Silicon, ça se fait depuis looooongtemps avec des outils comme Parallels ou UTM. Mais tart, l'outil en ligne de commande qui crée et clone des VM comme on le ferait avec des conteneurs, n'en est pas capable, parce que la virtualisation d'Apple sur laquelle il repose ne gère officiellement que macOS et Linux.
Sauf qu'un dev nommé Mustafa Akin, vient de publier un fork qui permet d'installer Windows 11 avec tart sans un seul clic.
Je viens de le tester sur mon Mac Studio M4 Max avec l'ISO française de Windows 11 et j'ai trouvé que ça fonctionnait super, d'où ce petit tuto.
Pour vous lancer là dedans, il vous faut donc un Mac Apple Silicon sous macOS 26.6 ou 27, Xcode pour compiler tout ça, et bien sûr une ISO de Windows 11 ARM64 ( faudra vous démerder ensuite avec la licence ). Par contre, faut le savoir, ce fork repose sur deux réglages privés d'Apple, non documentés, qu'une mise à jour de macOS pourra shooter à tout moment. Donc ne montez pas votre futur homelab là dessus sans un plan de repli.
Sur son site, Mustafa Akin publie un binaire tout fait, mais j'ai préféré compiler le programme car le script de création du paquet de son fork signe proprement l'application en local avec le droit de virtualisation qui va bien.
git clone --branch windows-guest-extras https://github.com/mustafaakin/tart.git
cd tart
git checkout e4c623c
./scripts/package-windows-preview.sh 0.1.0-windows-preview
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"
La commande export rend ce tart.app accessible au niveau du système prioritaire devant un éventuel tart déjà installé. Il ne reste alors qu'à lui passer votre ISO... tart téléchargera alors les pilotes virtio-win et WinFsp, fabriquera son propre média d'installation et démarrera Windows sans rien demander de plus.
tart create win11 --from-iso ~/Downloads/Win11_Arm64.iso
Ça m'a pris en tout et pour tout 26 minutes pour obtenir cette VM Windows fonctionnelle. Notez également que l'installation force l'anglais américain et que d'autres langues peuvent poser souci mais avec mon ISO française, l'interface est bien restée en français. Seul le clavier est resté en QWERTY au départ.
L'auteur écrit sur son blog que l'install de l'agent doit se faire manuellement pour l'instant mais ce qu'il a oublié de préciser c'est que le pilote viosock, celui qui relie le Mac à la VM, n'est pas dans la liste des pilotes que tart injecte (viostor, viogpudo, NetKVM, viorng et viofs). Résultat, chez moi, tart exec ne fonctionnait pas. Comme ce pilote se trouve dans l'ISO virtio-win que tart a gardée dans son cache, il suffit donc de le copier dans un dossier partagé, contenant l'agent publié avec la préversion :
hdiutil attach -readonly -nobrowse ~/.tart/cache/windows/sha256:303f7ae40dad495d6ae474fdc571df58958a4dbc5c37a522d80f9a203867949d.iso
mkdir -p ~/tart-share
cp -R /Volumes/virtio-win-0.1.302/viosock/w11/ARM64 ~/tart-share/viosock
hdiutil detach /Volumes/virtio-win-0.1.302
curl -L -o ~/tart-share/tart-guest-agent.exe https://github.com/mustafaakin/tart/releases/download/windows-preview-0.1.0/tart-guest-agent.exe
tart run win11 --dir=share:$HOME/tart-share
Comme la commande tart run garde la main, laissez-la tourner et ouvrez un second terminal pour la suite, en y refaisant l'export ci-dessous depuis le dossier tart, sinon vous appellerez un autre tart.
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"
Au démarrage, la session admin (mot de passe admin) s'ouvre alors toute seule et vous arrivez sur le bureau. Le dossier partagé apparaît sur le lecteur Z:, dans un dossier share. Ouvrez PowerShell en administrateur (et n'oubliez pas que le clavier est en QWERTY) pour installer le pilote, puis déclarer l'agent comme tâche lancée à l'ouverture de session, parce que c'est dans cette session que sont le presse-papiers et le bureau :
pnputil /add-driver Z:\share\viosock\viosock.inf /install
mkdir "C:\Program Files\Tart"
copy Z:\share\tart-guest-agent.exe "C:\Program Files\Tart\"
$a = New-ScheduledTaskAction -Execute "$env:SystemRoot\System32\conhost.exe" -Argument '--headless "C:\Program Files\Tart\tart-guest-agent.exe" --run-agent'
$t = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
$p = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Highest
Register-ScheduledTask -TaskName "Tart Guest Agent" -Action $a -Trigger $t -Settings $s -Principal $p
Start-ScheduledTask -TaskName "Tart Guest Agent"
Get-Service VirtioSocketWSP
Le service VirtioSocketWSP doit alors afficher Running. S'il n'existe pas, c'est que le pilote n'est pas passé et tart exec ne répondra pas. Relisez alors la sortie de pnputil et vérifiez que le dossier viosock contient bien viosock.inf.
Retournez ensuite dans le terminal du Mac et entrez cette commande pour connaitre le numéro de version du Windows :
tart exec win11 cmd /c ver
Microsoft Windows [version 10.0.26200.8037]
Informations système dans la VM : Windows 11 Famille, build 26200, sur une "Apple Virtualization Generic Platform" en ARM64
L'intérêt de tout ça c'est surtout d'avoir un Windows jetable. Vous devez arrêtez d'abord la VM de base avec tart exec win11 shutdown /s /t 0 puis pour cloner la VM, faites un : tart clone win11 w1 . C'est instantané, et y'a plus qu'à la démarrer avec un tart run w1 --no-graphics.
Avec --no-graphics ça démarre sans fenêtre et vous pouvez alors lancer ce que vous voulez avec tart exec. Ensuite pour tout stopper, un petit tart stop w1, et un tart delete w1 pour supprimer la VM et voilà...
En tout cas, n'en faites pas votre Windows de tous les jours car il n'y a ni son ni accélération graphique, pas de possibilité de suspendre le Windows et la virtualisation imbriquée se fige dès que Windows veut démarrer WSL2 ou Hyper-V.
La commande Get-Tpm confirme aussi l'absence de TPM. Et selon l'auteur, le disque est le point faible de ce Windows ARM 64 sous tart, en partie parce que tart rempli très vite les SSD avec ses logs. Pensez aussi à changer le mot de passe, puisque le compte est admin avec le mot de passe admin, et que SSH est ouvert sur le réseau interne de tart.
Mais pour tester des logiciels Windows ou scripter des trucs, ça tient bien la route.
Source : Mustafa Akin
La société de sécurité Depthfirst a publié un billet que j'ai trouvé intéressant dans lequel ils expliquent en gros que les conteneurs (Docker et compagnie) ne sont plus une barrière de sécurité suffisamment solide. La thèse du papier, c'est qu'il faut désormais partir du principe qu'un attaquant (hacker ou malware) saura sortir d'un conteneur quand il le veut, sans grande difficulté.
En effet, un conteneur comme ceux que font tourner Docker ou Kubernetes, donne à un programme l'impression d'avoir sa propre machine. Sauf qu'en réalité, il n'embarque pas de système d'exploitation. Tous les conteneurs d'un serveur passent par le même noyau Linux qui est celui de l'hôte et dont le rôle est de gérer pour eux la mémoire, le processeur ainsi que le réseau.
Toutefois, beaucoup d'organisateurs de CTF notamment s'y fient les yeux fermés et hébergent plusieurs épreuves sur le même serveur, chacune dans son conteneur, en comptant uniquement sur la sécurité de l'hôte. Mais c'est un faux sentiment de sécurité, j'en veux pour preuve ce bulletin de sécurité d'AWS daté de novembre 2025 où il est expliqué que l'entreprise ne considère plus les conteneurs comme une barrière de sécurité et ne s'en sert donc plus pour isoler ses clients les uns des autres.
Ce qui a changé depuis quelques mois, vous le savez, c'est le prix d'entrée de la recherche de failles puisqu'avec les modèles d'IA de pointe, même un attaquant avec des moyens modestes peut fabriquer sans effort, dès la publication d'une faille, un exploit contre des machines qui ne sont pas encore corrigées, alors qu'avant ça demandait de sérieuses compétences.
source : Depthfirst
Et les chiffres publiés par Depthfirst montrent que tout ça s'accélère puisque 249 CVE ont été publiées pour le noyau Linux en janvier, et en août on en a eu 1 650 !
Depthfirst relève également que sur les 36 CVE divulguées via le kernelCTF de Google, 13 sont réalisables via des interfaces ordinaires comme celles qu'un conteneur reçoit par défaut (dont les sockets locaux). En fait, on en croise sans le savoir dès qu'on passe systemd, Docker ou une base de données locale.
Le 24 juillet dernier, Depthfirst a même décroché une place au kernelCTF avec un exploit 0day (donc avant tout correctif) et aujourd'hui, le PoC est en accès libre sur GitHub. Rassurez-vous, côté noyau Linux, le correctif est sorti le 6 août mais malheureusement, côté Ubuntu la mise à jour au 24 septembre, affichait encore que le noyau de la 26.04 était en "Vulnerable, work in progress" et celui de la 24.04 en "Vulnerable". Bref, trouver des vulns ça va vite. Fixer ces vulns sur TOUTES les releases et les machines, ça prend du temps. Alors qu'avant c'était l'inverse. Bref, tout a été chamboulé et c'est un peu la merde maintenant niveau cybersécurité pour patcher rapidement.
Alors comment se protéger de tout ça ?
Hé bien la solution de Depthfirst va vous mettre en PLS car eux proposent carrément de ne plus partager le noyau. Ils recommandent à la place de migrer les charges non fiables vers des microVM, autrement dit des machines virtuelles légères où chaque charge aura son propre noyau. Le projet Firecracker en fait partie tout comme Kata Containers comme ça, en théorie, si un attaquant casse l'un de ces noyau, il ne compromet que sa propre instance et pas l'hôte dans son entièreté ni ses voisins.
Reste que Firecracker s'appuie sur KVM, la brique de virtualisation du noyau Linux de l'hôte. Et comme vous le savez, KVM a eu ses propres failles. En effet, cet été, la faille Januscape ouvrait en grand la porte de la machine physique à un attaquant pourtant enfermé dans sa VM, à condition bien sûr que l'hôte autorise la virtualisation imbriquée (une VM dans la VM). Alors certes, la surface d'attaque est plus petite mais loin d'être nulle.
Voilà, en attendant, si vous êtes sous Ubuntu 24.04 ou 26.04, surveillez bien la mise à dispo du prochain noyau. Canonical a d'ailleurs annoncé il y a peu, une publication hebdomadaire des noyaux pour tenter de compenser cet emballement.
Source : le billet de recherche de depthfirst
Les failles qui permettent à une machine virtuelle de s'échapper vers la machine qui l'héberge, ça court pas les rue. Et celle qui vient de débarquer est plutôt impressionnante ! En effet, il y a quelques jours, le chercheur Hyunwoo Kim a publié la CVE-2026-89775, qui est une évasion "invité vers hôte" bien planquée dans KVM (sur les archis ARM64). Pour rappel, KVM c'est la brique de virtualisation du noyau Linux. Et le score CVSS grimpe même jusqu'à 9,3 sur 10 ! Donc, autant dire que c'est du sérieux.
En fait, cette faille permet à la VM de lire et d'écrire dans la mémoire du noyau de l'hôte à grand coups de 64 bits à la fois ^^, sans même déclencher le garde-fou censé lui rendre la main. C'est possible à cause d'un simple calcul de taille qui retombe à zéro. Du coup, le noyau considère que ce zéro est une taille valide, ce qui permet d'éviter l'invalidation du cache mémoire.
Kim décrit deux façons de s'en servir. La première, c'est l' évasion classique où depuis une VM on peut débouler sur la machine hôte. Autant dire que c'est le cauchemar de quiconque loue de l'ARM à plusieurs clients.
La seconde, quand à elle, est plus vicieuse et souvent oubliée. Sur des distributions comme RHEL, le fichier /dev/kvm est ouvert à tout le monde en écriture. Cela permet ainsi à un simple utilisateur sans droits de se servir de la faille comme d'un ascenseur vers root, sans avoir à lancer la moindre VM.
Alors, est-ce que vous êtes concerné ??
Il y a de bonnes chances que non car sur ARM64, la virtualisation imbriquée n'est pas un mode par défaut de KVM. Il faut l'activer soi-même au démarrage avec kvm-arm.mode=nested, et être sur une puce assez récente.
Mais si vous administrez pour de vrai un hôte ARM64 avec la virtualisation imbriquée active, là oui ! Un uname -r vous donnera votre version mais sachez que rien n'est impacté avant le noyau 6.16 et que le trou est colmaté à partir des versions 6.18.51 et 7.2.5. Red Hat prévient qu'aucun contournement "propre" n'existe, donc ce sera le correctif ou rien, déso ^^.
À ce jour, le chercheur en sécurité, Kim, a livré le mécanisme mais pas de code d'exploitation. Donc, prenez le temps de corriger le problème sans traîner, mais ne paniquez pas non plus car ce n'est pas encore exploité activement.
Source : la divulgation de Hyunwoo Kim sur oss-security .
Si vous avez déjà voulu essayer une distrib sans toucher à votre machine, vous connaissez la corvée... Faut dénicher la bonne ISO (32/64 bits, ARM...etc), créer la VM, et passer 20 minutes dans des réglages pour que ce soit joli ou qu'on puisse y faire du copier coller dans l'hôte et l'invité. Boxes , l'application de virtualisation du projet GNOME, vous permet d'éviter tout ça et c'est top si vous aimez économiser un peu de jus de cervelle. Vous choisissez le système dans une liste, et il va chercher l'image et l'installe tout seul en VM pendant que vous faites autre chose, par exemple venir sur Twitch regarder mon live .
La liste couvre Debian, Fedora, Ubuntu, OpenSUSE, CentOS Stream, Red Hat Enterprise Linux et Windows. Pour son fonctionnement Boxes s'appuie sur du solide avec qemu-kvm, libvirt-glib et spice-gtk, donc le code de votre système invité s'exécute directement sur le processeur de l'hôte via KVM, pour obtenir ce que la doc de GNOME appelle des "performances proches du natif".
Une fois la VM créée, vous lui fixez la quantité de mémoire et le stockage qu'elle a le droit de prendre sur votre système, histoire qu'elle ne vous freeze pas la machine. Et bien sûr, vous pouvez prendre des instantanés pour la ramener à un état antérieur, ce qui est la fonction qu'on utilise tout le temps, si comme moi vous aimez casser volontairement vos OS avec des bidouilles alternatives des enfers.
Le reste, c'est du confort : vous branchez une clé USB sur votre machine et vous la redirigez dans la VM, le presse-papiers est partagé entre les deux, et vous déposez un fichier depuis votre gestionnaire de fichiers dans la fenêtre de Boxes pour l'envoyer à l'invité.
L'affichage des VMs dans Boxes se redimensionne tout seul quand vous changez la taille de la fenêtre, et il y a même de l'accélération 3D pour certains des systèmes supportés.
Après, cette "simplicité" se paye puisque des choses comme la config des adaptateurs réseau ou la mise à jour du matériel virtuel, n'est pas visible dans l'interface . Et comme le Flatpak embarque toute la pile de virtualisation dans son propre conteneur, vous n'irez pas rattraper ça en douce dans les fichiers. Donc si vraiment vous avez besoin de mettre les mains dans le cambouis au niveau de ces réglages-là, prenez plutôt virt-manager dès le départ, c'est fait pour.
Son auteur, Felipe Borges a d'ailleurs réécrit entièrement l'application en GTK4 et partage ses résultats depuis août . Cette version-là installe dorénavant Windows 11 sans le moindre contournement manuel, en configurant Secure Boot et un TPM virtuel automatiquement. C'était la fonction la plus réclamée sur la version classique et elle ajoute aussi un périphérique VSOCK, qui permet de se connecter directement en SSH sur les VM en systemd 256 ou plus récent.
Attention quand même, ça reste une bêta destinée aux tests et pas à la production, et son auteur conseille de sauvegarder les données de vos VM avant d'y aller. Il précise aussi qu'il travaille là-dessus sur son temps libre, en plus de maintenir GNOME Settings et de son job à temps plein chez Red Hat ! Encore un hyperactif !! lol. Donc soyez patient si vous ouvrez un ticket de support.
Pour ce qui est disponible aujourd'hui, Boxes ne tourne que sur Linux, la version stable est la 50.0 sortie depuis mars 2026, et ça se télécharge via Flathub comme ceci :
flatpak install flathub org.gnome.Boxes
Dernier truc à savoir, Felipe, le mainteneur, a proposé de retirer Boxes du cœur de GNOME pour en faire une application indépendante, et le retrait est programmé pour GNOME 52 en mars 2027. Flathub deviendra alors le seul canal officiellement supporté, et le nom perdra son "GNOME" pour devenir simplement Boxes. L'identifiant Flatpak ne bougeant pas, les installations existantes continueront de se mettre à jour sans rien casser.
Et si vous voulez comparer avec une autre solution similaire, je vous avais déjà parlé de QuickEmu pour monter des VM sans y passer l'après-midi, mais Boxes, lui, joue sur le terrain du tout à la souris, et ça j'imagine que ça vous plait plus !
Merci à Hub pour le partage !!
Ce serait trop cool non, si avec un double-clic sur un .docx dans votre gestionnaire de fichiers Linux, Word s'ouvrait directement ? Et je ne vous parle pas d'un bureau Windows complet en plein écran ou d'une session de bureau à distance. Juste une fenêtre Word tout ce qu'il y a de plus classique, avec son icône dans votre barre des tâches, épinglable et "alt-tabbable" comme le reste.
Hé bien, c'est ce que fait
WinPodX
, qui fait tourner un conteneur Windows sous KVM en arrière-plan et découpe l'affichage application par application via FreeRDP RemoteApp. Comme ça, les liens mailto: partent vers Outlook ou les schémas slack: ou vnc: vers l'application qui les a déclarés.
Tout ce qui est presse-papiers, son, imprimantes et votre dossier personnel sont partagés d'office, et le conteneur se met en pause tout seul quand personne ne s'en sert.
Jusque-là, WinApps dont je vous ai déjà causé, qui fait tourner Office sous Linux , faisait déjà l'essentiel avec les fenêtres détachées, le dossier personnel partagé, le clic droit qui envoie un fichier vers une application Windows. Mais WinPodX se distingue aussi dans l'autre sens puisque vos applications Linux remontent également dans le menu "Ouvrir avec..." du Windows, et dans un dossier "Linux Apps" du menu Démarrer. Bref, l'accès aux apps et aux fichiers marche dans les 2 sens, pour plus de transparence dans vos usages.
Si ça vous intéresse, sachez qu'il vous faut une licence Windows valide, car WinPodX ne la fournit pas (logique), que la virtualisation doit être activée dans le BIOS, avoir un accès à /dev/kvm, 8 Go de RAM et une trentaine de gigas de libre. La première installation prend cinq à dix minutes le temps de télécharger l'ISO, et les suivantes sont quasi instantanées.
Pour l'installer :
curl -fsSL https://raw.githubusercontent.com/kernalix7/winpodx/main/install.sh | bash
Il y a également un paquet pour openSUSE, Fedora, Debian, Ubuntu, Arch et NixOS, un AppImage pour les autres. C'est sous licence MIT, et sans aucune télémétrie puisque celle de Windows a été elle-même coupée par défaut. Ah et l'interface du OuinOuin peut être configurée en français.
Par contre, pas d'accélération GPU, ce qui exclut les jeux et la 3D à moins de monter un passthrough à la main. Préférez Wine pour ça...
Depuis 16 ans, il y a une énorme faille qui fait dodo dans le coeur de tout ce qui gère la virtualisation sous Linux et personne ne l'avait remarqué, jusqu'à ce que Hyunwoo Kim, un chercheur en sécurité connu sous le pseudo @v4bel débarque. Ce dernier vient de dénicher un use-after-free dans le shadow MMU de KVM, ce bout de code que KVM partage entre les processeurs Intel et AMD. Il a baptisé sa trouvaille Januscape (CVE-2026-53359), et croyez-moi, le scénario a de quoi filer des sueurs froides à n'importe quel hébergeur...
En pratique, quand vous louez une VM dans le cloud, vous y êtes root (normal, c'est votre instance). Mais si l'hôte autorise la virtualisation imbriquée, hé bien la faille vous ouvre en grand la porte vers la machine physique. Le code de démonstration que Kim a publié se contente de faire planter l'hôte, et il garde sous le coude un second exploit, non divulgué publiquement celui-là, qui transforme le même bug en exécution de code root sur l'hôte. Et il n'a pas trouvé tout ça par hasard, puisqu'il participait au kvmCTF de Google, un programme qui paie jusqu'à 250 000 dollars pour une évasion complète d'une VM vers son hôte...
À ce stade, l'isolation censée séparer les locataires d'un même serveur vole en éclats, les VM de vos voisins de palier comprises.
Le code fautif traîne depuis août 2010, du temps du noyau 2.6.36 et Kim présente d'ailleurs Januscape comme la première évasion d'une VM vers son hôte qui fonctionne aussi bien sur Intel que sur AMD, à sa connaissance en tout cas.
Maintenant, avant de couper le wifi et de partir élever des chèvres dans le Larzac, deux petites nuances quand même car l'attaque réclame deux conditions réunies : être root dans la VM invitée, et que l'hôte expose la virtualisation imbriquée. Pas mal d'hébergeurs ne l'activent pas, donc c'est pas non plus une apocalypse universelle. Par contre, pour ceux qui l'activent, c'est game over.
Mais bonne nouvelle, le correctif est déjà là donc si vous administrez des serveurs KVM, mettez à jour maintenant. Et si vous ne pouvez pas patcher tout de suite, la parade consiste à désactiver la virtualisation imbriquée en attendant, avec kvm_intel.nested=0 sur de l'Intel ou kvm_amd.nested=0 sur de l'AMD.
VENOM s'échappait déjà d'une VM en 2015 via un vieux driver de disquette, et plus récemment une faille kernel planquée neuf ans offrait un accès root sur une machine Linux. Ces "fantômes" dorment longtemps dans le noyau, et ils choisissent toujours le pire moment pour se réveiller. Voilà, comme d'autres failles Linux à patcher d'urgence , celle-ci mérite tout de suite votre attention.
Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.
Pour en profiter, tapez la commande suivante :
wsl --update --pre-release
Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.
WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :
wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde
Ce qu'on lance là c'est bien une image en provenance de LinuxServer dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.
Et la cerise sur le gâteau, c'est le support GPU. Vous collez --gpus all sur un conteneur PyTorch et CUDA répond présent, sans config tordue. C'est énorme pour ceux qui font du dev IA localement sous Windows. Vous allez enfin pouvoir entrainer ou inférer dans un conteneur propre sans avoir à vous taper avec les drivers.
Microsoft pousse aussi des SDK (packages NuGet pour C, C++ et C#) histoire de piloter tout ça depuis vos applis si ça vous amuse.
Maintenant, vous vous interrogez sûrement sur les perfs de WSLC et c'est bien normal. De ce que j'ai lu, comme WSLC passe par VirtioFS pour son système de fichiers par défaut, les accès seraient 2 fois plus rapide. J'emploie le conditionnel car personne n'a encore réalisé de benchmark indé mais si ça se vérifie, ça va être énorme tant le partage de fichiers entre Windows et un conteneur Linux c'était la misère. Là vos builds vont respiiiiirer !!!
Et pour calmer les inquiets : Docker Desktop, Podman et Rancher Desktop ne disparaissent pas, rassurez-vous. Microsoft précise même que ces outils profiteront de changements de bas niveau apportés par WSLC. C'est donc une fondation, et absolument pas une déclaration de guerre.
C'est pour le moment dispo en public preview, donc attendez-vous à quelques bugs, et la mise à dispo pour tous, ce sera normalement pour cet automne. En tout cas, je suis content de voir cette évolution. Ça arrive pile au moment où Apple fait pareil de son côté , ce qui en dit long sur où va le vent. Donc, si vous aviez décroché de WSL, c'est peut-être le moment de remettre le nez dedans .
À tester sur une machine de dev, pas en prod, hein ! Et vous me direz si le VirtioFS tient ses promesses.
Quand on est habitué à Linux et qu'on se retrouve avec un Mac, même si c'est une base unix, c'est déroutant. Heureusement, Apple est de plus en plus ouvert au monde du libre et vient de publier la version 1.0 de Container , avec dedans des "container machines" qui ressemblent furieusement à WSL. Et ça nous permet comme ça d'avoir le meilleur des deux mondes : un macOS pour le quotidien, et un vrai Linux pour vos folles bidouilles.
Vous vous souvenez forcément de mon article où je vous présentais Apple Container , cet outil écrit en Swift qui fait tourner des conteneurs Linux dans des petites machines virtuelles. Et bien un an plus tard, le projet passe en 1.0, pile pour la WWDC, et la grosse nouveauté c'est donc ce mode "machine".
Le CLI container en action, sobre comme un terminal qui bosse ( Source )
Il s'agit d'un environnement qui vous permet de faire tourner de vraies distributions Linux comme Ubuntu, Debian ou Alpine, et pas juste un conteneur modelé sur une application. La machine lance le système d'init de l'image, donc un systemctl start postgresql fonctionnera comme sur un vrai serveur.
Et à la reconnexion, à partir du même terminal ou d'un autre, l'état de la machine n'est pas perdu. Surtout, elle mappe automatiquement votre utilisateur et votre répertoire home. Votre repo vit ainsi dans le $HOME de macOS, du coup vous éditez avec votre IDE côté Mac et vous compilez côté Linux, sans étape de copie entre les 2.
Pour la prise en main, entrez les commandes suivantes en prenant soin de remplacer alpine par la distrib de votre choix :
container machine create alpine:latest --name dev
container machine run -n dev whoami # votre user, pas root
container machine run -n dev # shell interactif
Ensuite, pour aller plus loin, vous pouvez le faire via un terminal en choisissant l'image que vous voulez ou concevoir votre propre image : n'importe quelle image Linux avec un /sbin/init fait l'affaire.
Après vous l'aurez compris parce que vous êtes les plus malins, il vous faut un Mac Apple silicon, et si ça se lance encore sur macOS 15, c'est avec des limitations et sans filet car les mainteneurs ne s'occupent actuellement que des bugs reproductibles sur macOS 26. Et migrer toute votre stack dev dessus aujourd'hui, c'est ce que je ne vous recommande pas sachant que c'est tout frais...
Mais ainsi, grâce à ces machines, plus besoin de choisir entre un Mac et une distribution Linux. Après est-ce que ça enterre OrbStack et Colima ? Pas tout de suite je pense, car ces outils tournent depuis des années sur des Mac Intel et des macOS pas tout neufs, alors que là, Apple exige sa puce maison.
Ah et côté x86, container fait aussi tourner des images amd64 via Rosetta, alors c'est le bonheur ! Et si le sujet vous branche, j'avais aussi causé de Mocker , un clone Docker natif pour Mac, et de WSL côté Windows si pour vous Mac c'est pas encore un projet ^^.
Bref, l'installeur signé est sur la page des releases , vous faites un petit container system start, et hop hop hop, à vous le kif du Linux sur votre petit Mac !
Docker Desktop bouffe la RAM comme vous le saucisson à l'apéro. Et même quand vous n'utilisez pas cette RAM, d'autres outils comme Lima ou Colima prennent aussi de la RAM.
Mais c'était sans compter sur
smolvm
, le projet de BinSquare et de l'équipe smol-machines, qui s'attaque au problème par un autre angle, à savoir utiliser des microVMs hardware-isolées qui bootent en moins de 200 millisecondes, qu'on configure en TOML, et qu'on peut packer dans un seul binaire .smolmachine qui tournera sur n'importe quel Mac ou Linux compatible.
Pas de daemon ni de service à lancer en background, non, c'est juste un bon vieil outil CLI codé en Rust qui boote une VM par workload et s'éteint quand c'est fini !
Ainsi, quand vous tapez :
smolvm machine run --image alpine -- sh -c "ma commande"
ça vous sort un noyau Linux complet avec son propre kernel, isolé via Hypervisor.framework sur Mac ou KVM sur Linux et tout ça en moins de temps qu'il n'en faut à Docker Desktop pour afficher sa fenêtre de démarrage. LOL
Le réseau est désactivé par défaut, mais si vous voulez l'activer, vous pouvez whitelister uniquement les domaines autorisés. Cette approche "deny by default" est rare dans l'écosystème conteneur, où en général on ouvre le réseau d'abord et on filtre après.
La fonctionnalité qui sort vraiment du lot, c'est surtout le packing en format .smolmachine. Concrètement, vous prenez votre image Docker (Python 3.12, Postgres, ce que vous voulez...), vous lancez :
smolvm pack create --image python:3.12-alpine -o ./python312
Et hop, magie magie, vous avez un exécutable totalement autonome avec tout ce qu'il faut dedans : kernel, rootfs, dépendances et tutti quanti comme disent les Allemands !
Plus besoin comme ça, d'installer quoi que ce soit du côté du destinataire de votre app. Vous balancez simplement votre binaire à un collègue, il le lance, et ça marche. Il est content, vous aussi, c'est trop bien, y'a plus qu'à aller boire ce truc dégeu qu'on appelle dans le sud, "un petit jaune" pour célébrer ça !!
Sous le capot, le moteur de virtualisation s'appuie sur libkrun , une bibliothèque VMM développée par Red Hat dans le cadre de l'initiative rust-vmm. Pour les noobzzzz, rust-vmm est un effort communautaire qui partage des composants Rust de virtualisation entre plusieurs projets : Firecracker (AWS), Cloud Hypervisor (Intel), crosvm (Google), libkrun (Red Hat) et donc smolvm.
Du coup les améliorations sur la mémoire ou la sécurité bénéficient à tous en parallèle. Côté kernel, smolvm embarque libkrunfw, un noyau custom optimisé pour démarrer hyper vite. J'ai testé, ça tient sa promesse < 200 ms !
La mémoire est élastique via virtio balloon ce qui fait que le host n'engage que ce que le guest utilise vraiment et récupère le reste automatiquement. Et les vCPUs dorment dans l'hyperviseur quand ils sont idle (en attente), ce qui permet d'over-provisionner sans payer le prix.
Côté sécu, y'a des détails qui sont cools aussi comme le SSH agent forwarding du host qui est exposé au guest sans jamais que les clés privées n'entrent dans la VM. En effet, c'est l'hyperviseur qui fait barrière donc vous pouvez cloner un repo privé depuis une VM jetable, comme un cochon, sans risquer d'exfiltrer vos identifiants si le code que vous lancez est foireux.
Et chaque workload a son propre kernel, donc une faille dans le kernel guest reste cantonnée à cette VM. Top hein ? Comparé à un conteneur Docker classique où une CVE kernel touche tout le host, c'est un autre niveau d'isolation.
Au niveau des concurrents, Firecracker (AWS) tourne uniquement sous Linux et vise les workloads serverless du cloud, mais pas le poste dev. Kata Containers de son côté fait du microVM mais boot en environ 500ms et nécessite une stack containerd lourde.
QEMU est puissant c'est sûr, mais boot en 15 à 30 secondes selon la config, donc oubliez, la vie est trop courte ! Quant à OrbStack dont je vous parle tout le temps puisque c'est l'alternative à Docker Desktop sur Mac qui est la plus aboutie aujourd'hui, ça reste quand même un outil proprio qui se repose sur Docker.
smolvm lui, boxe dans une autre catégorie puisque c'est une lib SDK embarquable, et pas juste un CLI, et son format .smolmachine n'a pas d'équivalent direct. C'est donc plus proche de l'esprit de Nix ou des binaires statiques Go, mais avec une isolation hardware réelle.
Sachez-le, en 2026, environ 42% des commits GitHub viennent de code généré ou assisté par IA. Je sais, ça en défrise pas mal mais c'est la nouvelle réalité.
Sauf qu'à chaque fois que vous lancez un script Python ou un paquet npm non relu, codé par une IA, vous prenez potentiellement un risque. En effet, à chaque fois, que vous donnez à du code potentiellement malveillant un accès direct à vos credentials, votre système de fichier ou encore votre réseau, vous vous exposez.
Ce bon vieux chmod +x && ./run.sh servi avec du café et beaucoup d'espoir, c'est terminé ! smolvm vous propose de basculer vers un modèle où l'isolation est l'état par défaut, et où ouvrir le réseau ou votre système de fichiers est une décision vraiment explicite. Donc parfait pour laisser des agents IA faire leur vie sur vos projets sans prendre de risques.
Notez que le support GPU est dans une branche séparée, et pas encore mergé. Et le projet est principalement piloté par BinSquare avec un Discord modeste derrière, et pas une fondation booster aux milliards d'Amazon ou de Google. Du coup ne déployez pas ça en prod sans backup... Mais pour du dev, de la sandbox d'agents IA, ou tout simplement pour distribuer votre binaire, c'est déjà très solide.
Et comme ça bouffe moins de RAM que Docker Desktop, sur un MacBook avec 16 Go, la différence se sent immédiatement.
Pour l'installer, ça passe par curl :
curl -sSL https://smolmachines.com/install.sh | bash
ou un download manuel depuis les releases GitHub.
Lancez ensuite
smolvm --help
ou ce hello world :
smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"
Et à vous de jouer !
L'interface web de Proxmox (l'outil de virtualisation que tout bon homelabber connaît), c'est bien... pour UN serveur. Dès que vous commencez à empiler les nodes et les clusters, ça devient vite le bazar avec 15 onglets ouverts. PegaProx , c'est tout simplement un dashboard open source qui unifie tout ça dans un seul écran. Et vous allez voir, le truc cool, c'est que ça gère aussi les clusters XCP-ng !
L'interface de PegaProx - une vue unifiée de tous vos clusters Proxmox et XCP-ng
Concrètement, vous branchez tous vos hyperviseurs sur cette interface web (port 5000) et hop, vous avez la vue complète. VMs, conteneurs, métriques de perf... tout remonte en temps réel via Server-Sent Events. Du coup, plus besoin de jongler entre les interfaces de chaque node pour savoir quel serveur rame.
Côté fonctionnalités, accrochez-vous les amis parce que pour une beta, c'est déjà bien garni ! Migration live de VMs entre nodes, gestion du stockage Ceph, consoles navigateur via noVNC et xterm.js, et même de la migration cross-hypervisor entre ESXi, Proxmox VE 8.0 et XCP-ng (encore expérimental côté ESXi, mais ça avance). Y'a aussi des règles d'affinité pour placer vos VMs, du rolling update avec évacuation automatique, et des alertes sur les seuils CPU/RAM/disque. Pour une beta, c'est assez dingue ce qu'ils ont déjà mis dedans.
Côté sécurité, c'est pas en reste non plus. Y'a du RBAC avec 3 rôles (Admin, Operator, Viewer, pas plus pas moins), du TOTP pour le 2FA, de l'intégration LDAP et OIDC compatible Active Directory, Entra ID, Keycloak ou Google Workspace, du chiffrement AES-256-GCM pour stocker les credentials en base, et même du scan de CVE via debsecan. Autrement dit, ils ont pensé aux admins sérieux. Pour ceux qui ont déjà configuré un provider OIDC sur leur homelab , ça se branche directement.
Pour l'installer, le plus simple c'est Docker. Un docker compose up -d, 30 secondes d'attente, et c'est plié.
Mais y'a aussi un script de déploiement automatique, un repo APT communautaire maintenu par gyptazy, ou le classique git clone + pip pour les puristes. Une fois lancé, vous pointez votre navigateur sur https://votre-ip:5000, et un assistant vous accueille avec les identifiants par défaut (pegaprox/admin, à changer immédiatement bien sûr). L'interface est dispo en 5 langues : français, anglais, allemand, espagnol et portugais.
D'ailleurs, si vous utilisez déjà ProxMenux pour administrer votre Proxmox en terminal, les deux sont en fait complémentaires. Disons que ProxMenux couvre l'admin système en ligne de commande, alors que le dashboard apporte la vue unifiée multi-clusters en web. Initialement j'aurais dit que c'était redondant, mais non, ça se marie plutôt bien. Et y'a même un système de plugins avec un portail client pour vos utilisateurs et une page de statut publique à la StatusGator.
Attention c'est comme je vous le disais, encore une beta. L'OIDC avec Authentik par exemple, ça fonctionne pour le login mais les groupes ne remontent pas encore correctement (retour d'un lecteur qui l'utilise au quotidien).
Par contre si vous n'avez qu'un seul serveur Proxmox, honnêtement c'est un peu overkill, l'interface native suffit largement. Quelques glitchs traînent ici ou là, et l'API Token pour se connecter à la place de root n'est pas super bien documenté. Mais le projet avance vite donc c'est plutôt bon signe !
Bref, ça promet pas mal. Merci à Maxime pour la découverte !
