Jeux vidéoActualité
Fortnite viendra sur Linux, à condition de verrouiller le PC
Pour jouer à Fortnite sur Linux, il faudra un système qui prouve au démarrage qu’il n’a pas été modifié : Epic en a détaillé les huit conditions le 14 octobre. Le Steam Deck et plusieurs distributions populaires n’y répondent pas encore.
Les joueurs sous Linux attendaient Fortnite depuis des années : Epic Games leur a promis le 14 octobre que le jeu viendrait, sans fixer de date, et à une condition, que leur ordinateur démarre d’une façon que l’anti-triche peut vérifier. L’éditeur a ouvert le même jour la préversion de son nouveau lanceur, proposée « pour la première fois » sur Linux, et publié un billet technique qui pose huit exigences système. Fortnite arrivera par ce lanceur « une fois que [le nouvel anti-triche] fonctionnera avec une masse critique de responsables de distributions », écrit Epic.
Le frein n’a jamais été le jeu lui-même, mais la triche. Easy Anti-Cheat (EAC), l’anti-triche d’Epic utilisé par de nombreux jeux en ligne, accepte les jeux Linux depuis 2014, et depuis 2021 les jeux Windows lancés sous Linux grâce à Wine ou Proton, des couches de compatibilité. Mais chaque studio doit activer cette option, et beaucoup ne l’ont pas fait, parce que la version Linux « ne pouvait pas offrir le même niveau de protection » que sur Windows, reconnaît Epic : « C’est pourquoi Fortnite n’est pas encore disponible sur Linux. » La triche est devenue, selon l’éditeur, un « marché d’un milliard de dollars », vendu par abonnement.
Sur Windows un pilote, sur Linux des preuves
Sur Windows, EAC s’appuie « largement sur un pilote noyau » : un programme logé au cœur du système d’exploitation, le noyau, là où tout est permis, qui démarre avec le jeu et s’arrête à sa sortie. Ces anti-triche installés dans le noyau sont contestés. En 2024, deux chercheurs, Christoph Dorner et Lukas Daniel Klausner, en ont comparé quatre aux rootkits, ces logiciels malveillants qui se cachent dans le noyau : Vanguard et FACEIT présentaient selon eux un comportement de rootkit, pas EAC (2 points sur 7, quand le seuil est à 4), même s’ils relevaient qu’il envoie au serveur la liste des pilotes et modules présents en mémoire, « que le joueur soit soupçonné de tricher ou non ».
Pour Linux, Epic renonce à cet équivalent. EAC Linux v2 « n’installe ni ne charge de module noyau », affirme la foire aux questions du billet. Il repose sur un service systemd (systemd est le logiciel qui lance les services de la plupart des distributions), installé au premier lancement d’un jeu protégé et actif seulement pendant la partie, sur des programmes eBPF (de petits programmes que le noyau accepte d’exécuter après les avoir contrôlés) et sur des protections que Linux contient déjà.
La logique se lit dans ses exigences : au lieu d’aller surveiller le noyau de l’intérieur, l’anti-triche demande que ce noyau soit d’une origine connue, et que la machine le prouve. La pièce maîtresse est le TPM, un composant de sécurité qui permet à l’anti-triche, écrit Epic, de « savoir quel code s’est exécuté au démarrage sans s’exécuter lui-même au démarrage ».
Huit conditions, une chaîne de confiance
Chaque étape du démarrage vérifie ou enregistre la suivante : le micrologiciel de la carte mère (UEFI, le logiciel qui démarre le PC), puis le gestionnaire de démarrage, puis le noyau et ses modules. Les huit conditions d’Epic verrouillent chacune un maillon.
| Condition | Ce que c’est | Ce qu’elle doit empêcher, selon Epic |
|---|---|---|
| 1. Noyau et modules signés par une clé reconnue | Le noyau et les pilotes chargés ont été compilés et signés par une organisation de la liste d’Epic | Un noyau modifié qui contournerait les contrôles et « renverrait de fausses données » à l’anti-triche |
| 2. TPM 2.0 activé dans le BIOS | Composant qui tient un journal de démarrage : on peut y ajouter des mesures, jamais en effacer | Rien seul : il fournit la preuve dont dépendent les autres conditions |
| 3. Secure Boot, avec des clés reconnues seulement | Le micrologiciel ne lance qu’un gestionnaire de démarrage signé, qui vérifie à son tour le noyau | Les triches qui se chargent pendant le démarrage |
| 4. Démarrage mesuré | Chaque étape inscrit dans le TPM une empreinte de ce qu’elle lance | Sans ces mesures, aucune preuve ; systemd-boot et GRUB les font « en général par défaut » |
| 5. IOMMU activée (sauf consoles portables) | Contrôleur matériel qui filtre l’accès des périphériques à la mémoire | Les cartes conçues pour tricher, qui lisent la mémoire du jeu sans passer par le processeur |
| 6. Verrouillage du noyau en mode « intégrité » | Même l’administrateur (root) ne peut plus modifier le noyau en marche | Charger un module non signé, écrire dans la mémoire physique ou dans les registres du processeur |
| 7. kexec désactivé | kexec charge un nouveau noyau sans redémarrer la machine | Lancer un noyau modifié sans laisser de trace dans le journal de démarrage |
| 8. BPF LSM chargé | Permet à des programmes eBPF de se brancher sur les points de contrôle de sécurité du noyau | Qu’un autre programme lise ou écrive dans la mémoire du jeu ; repérer des triches chargées autrement |
Le TPM 2.0 est la même version que celle exigée par Windows 11, qui demande aussi un PC « compatible Secure Boot » ; Epic va plus loin en exigeant que Secure Boot soit activé. L’éditeur prévient que ces fonctions « ne sont pas disponibles sur toutes les distributions et peuvent exiger des changements de configuration », et veut que le verrouillage et la désactivation de kexec soient demandés « explicitement » au démarrage : même sur une distribution reconnue, il faudra sans doute retoucher des réglages.
Le détail technique, condition par condition
- Clés reconnues. Epic parle de clés well-known. Elles valent pour la base de signatures de Secure Boot (db) et pour les MOK (Machine Owner Keys, clés que le propriétaire ajoute lui-même au petit chargeur shim, signé par Microsoft, qui permet à la plupart des distributions de démarrer avec Secure Boot).
- Démarrage mesuré. Les registres du TPM (PCR) ne peuvent qu’être « étendus » : chaque nouvelle mesure se combine à la précédente. Selon la documentation de systemd, systemd-boot y inscrit notamment la ligne de commande transmise au noyau (registre 12) : c’est ce qui rend visible une option de démarrage modifiée.
- IOMMU. Epic exige l’IOMMU activée et le mode passthrough désactivé. Dans ce mode, selon la documentation du noyau (paramètre
iommu.passthrough=), l’accès direct à la mémoire des périphériques (DMA) « contourne l’IOMMU ». L’exigence ne vaut que pour les machines « non portables ». - Verrouillage. Le noyau prévoit deux niveaux, réglés par le paramètre
lockdown=: « integrity » coupe les fonctions qui permettent de modifier le noyau en marche ; « confidentiality » coupe en plus celles qui permettent d’en extraire des informations confidentielles. Epic demande le premier. - BPF LSM. Les modules de sécurité Linux (LSM) sont des points de contrôle placés dans le noyau. Le BPF LSM permet à des programmes eBPF d’y imposer des règles d’accès, selon le noyau ; c’est ce qui remplace, pour EAC, le pilote de Windows.
Ubuntu et Bazzite sur la liste, Arch et le Steam Deck dehors
Le tri se fait d’abord par la liste des clés reconnues. Dans sa version du 14 octobre, qu’Epic dit vouloir étendre :
- Canonical (Ubuntu et ses dérivées, comme Linux Mint) ;
- Fedora (et ses dérivées, comme Silverblue) ;
- Universal Blue (Bazzite, Bluefin, Aurora et leurs dérivées) ;
- Debian (et ses dérivées) ;
- openSUSE (et ses dérivées) ;
- SUSE Linux Enterprise ;
- Rocky Linux ;
- AlmaLinux ;
- Microsoft UEFI CA, l’autorité qui signe des composants extérieurs à Microsoft, comme shim, le petit chargeur qui permet à la plupart des distributions de démarrer avec Secure Boot.
Arch Linux, Gentoo, NixOS ou CachyOS, construite sur Arch, n’y figurent pas. Or, dans l’enquête matérielle de Steam de septembre 2026, où Linux pèse 3,05 % des utilisateurs, les trois premières lignes Linux sont CachyOS (0,55 % de l’ensemble), SteamOS, le système du Steam Deck (0,53 %), et Arch (0,33 %). Pour NixOS, l’obstacle est de principe : son outil de démarrage sécurisé crée des clés propres à chaque utilisateur, qui « ne compteraient jamais », note un contributeur sur le forum du projet.
Le Steam Deck « ne prend pas en charge les fonctions requises », écrit Epic, sans préciser lesquelles ; l’éditeur dit discuter « activement » avec Valve et « espère » le prendre en charge plus tard. Il dispense d’ailleurs déjà les machines portables de l’exigence sur l’IOMMU.
Les cartes graphiques NVIDIA sont le cas le plus délicat. Leur pilote est développé à part du noyau, et Epic, qui le cite, exige qu’un tel module soit « construit par une organisation et signé avec une clé reconnue ». Il exige aussi que toutes les MOK enregistrées, les clés ajoutées par le propriétaire de la machine, soient reconnues, puisqu’elles servent à valider les modules. Sur Fedora, la méthode documentée par RPM Fusion consiste justement à compiler le pilote sur la machine, à le signer avec une clé générée localement, puis à enregistrer cette clé comme MOK. À la lecture des deux textes, cette configuration ne remplit pas la condition d’Epic, et le contributeur NixOS relève que Fedora « a le même problème ». Epic ne commente pas ce cas. Ubuntu, de son côté, propose des pilotes NVIDIA précompilés et signés par Canonical, dont la clé figure sur la liste : à notre lecture, ceux-là devraient passer, ce qu’Epic ne précise pas. Bazzite, qui ne démarre avec Secure Boot qu’une fois la clé d’Universal Blue enregistrée comme MOK, est dans le cas inverse : cette clé figure sur la liste d’Epic.
Le lanceur, lui, a sa propre liste : Ubuntu 22.04 ou plus récent, Fedora 43 ou plus et Debian 12 ou plus, selon GamingOnLinux, qui cite la foire aux questions de la préversion. Les autres distributions « peuvent fonctionner », sans être testées.
Ce que le joueur garde
La foire aux questions d’Epic répond à plusieurs inquiétudes. Le service ne tourne pas en permanence : il « démarre seulement quand un jeu protégé démarre et s’arrête quand le jeu se ferme ». Il n’est pas nécessaire de garder sa machine verrouillée : les conditions sont vérifiées au lancement du jeu, et l’on peut conserver une entrée de démarrage séparée, avec le noyau et les options requis, à choisir pour jouer. Ses propres clés Secure Boot restent possibles pour les autres entrées, à condition de les inscrire dans la base db, la liste de clés du micrologiciel, et non comme MOK. Un joueur qui lance un jeu protégé sans remplir les conditions ne sera pas banni : il verra « simplement un message d’erreur ».
Tous les jeux EAC ne basculeront pas d’office. Ceux qui acceptent déjà Linux pourront garder l’ancienne version, « pour une compatibilité maximale », ou passer à la v2. Fortnite servira de banc d’essai ; EAC Linux v2 sera ensuite proposé aux autres studios.
Une liste de clés tenue par Epic
Le cœur du dispositif est une liste que l’éditeur contrôle : c’est elle qui dit quelle distribution permet de jouer. Epic dit vouloir la publier en logiciel libre et accepter des contributions, mais la tiendra lui-même « pour commencer ». Il invite les responsables de distributions à le contacter pour y faire entrer leurs clés, et annonce un débat public « plus tard cette année » avec Jef Spaleta, responsable du projet Fedora. Les exigences elles-mêmes doivent encore évoluer, prévient l’éditeur.
Epic ne promet pas non plus l’étanchéité : l’anti-triche « exige toujours des mises à jour régulières », répond la foire aux questions, et l’objectif est seulement qu’un joueur « croise rarement un tricheur ».
Reste le calendrier, qui n’appartient plus tout à fait à Epic : Fortnite viendra quand assez de distributions auront aligné leurs réglages sur ces huit conditions. Pour les joueurs de Linux, la question n’est donc plus de savoir si leur machine fait tourner le jeu, mais si leur distribution signe ce qu’elle démarre.
Citations traduites de l’anglais par la rédaction.
