Easy Anti-Cheat Linux v2: Secure Boot bepaalt toegang

Epic Games heeft in zijn aankondiging van 14 oktober 2026 EAC Linux v2 gepresenteerd: een nieuwe uitvoering van Easy Anti-Cheat die eerst in Fortnite wordt beproefd en waarvoor Secure Boot, TPM 2.0, gemeten opstarten en ondertekende kernelonderdelen nodig zijn. Die proef is gepland; Fortnite is daardoor nog niet beschikbaar op Linux. Of een bestaande pc aan de eisen voldoet, hangt af van de gebruikte opstartketen, kernelinstellingen en geladen modules.

Het verslag van Phoronix beschrijft een systemd-dienst en eBPF-programma’s, zonder Linux-equivalent van de Windows-kerneldriver. Voor spelers is daarom niet alleen de distributienaam van belang. Ook de sleutels waarmee de kernel en externe stuurprogramma’s zijn ondertekend, tellen mee.

Wat EAC Linux v2 op het systeem gebruikt

Bij de eerste start van een beschermd spel vraagt EAC Linux v2 om installatie van een anti-cheatdienst voor systemd. Volgens de aangekondigde opzet start die dienst wanneer een beschermd spel draait en stopt hij na het afsluiten. De controle van de systeemvereisten vindt plaats bij het starten van een beschermd online spel. Een afzonderlijke opstartoptie met de vereiste kernel en instellingen is daardoor mogelijk.

De nieuwe uitvoering installeert of laadt zelf geen anti-cheatkernelmodule. Wel gebruikt zij bestaande beveiligingsfuncties van de Linux-kernel en eigen eBPF-programma’s via de BPF Linux Security Module. Die kunnen via kernelhooks de toegang van andere processen tot het geheugen van een beschermd spel beperken en activiteit volgen die op valsspelen kan wijzen. eBPF-logica werkt dus binnen de kernel, maar is iets anders dan een afzonderlijk laadbare kerneldriver zoals de Windows-uitvoering gebruikt.

Er bestaat al Easy Anti-Cheat-ondersteuning voor Linux-spellen en, wanneer een ontwikkelaar die inschakelt, voor Windows-spellen via Wine of Proton. Ontwikkelaars van spellen die de bestaande ondersteuning gebruiken, kunnen volgens het plan bij die uitvoering blijven of overstappen op v2. De nieuwe eisen gelden dus voor spellen die de nieuwe bescherming daadwerkelijk inzetten.

Waarom Secure Boot alleen niet genoeg is

Secure Boot moet actief zijn en de opstartketen mag alleen sleutels gebruiken die voor EAC Linux v2 als vertrouwd gelden. De kernel waarmee het beschermde spel draait, moet met zo’n sleutel zijn ondertekend. Voor geladen kernelmodules geldt eveneens een eis aan de herkomst en handtekening: ze moeten door een organisatie zijn gebouwd en met een bekende sleutel zijn ondertekend. Dat raakt vooral modules die buiten de broncode van de distributiekernel worden onderhouden.

Daarnaast moet het systeem de opstartketen meten. Tijdens het starten kunnen firmware, bootmanager en kernel gegevens vastleggen in registers van de TPM. Secure Boot controleert welke onderdelen mogen starten; gemeten opstarten legt vast welke onderdelen daadwerkelijk zijn gestart. Een ingeschakelde Secure Boot-optie toont op zichzelf dus nog niet aan dat de vereiste metingen aanwezig zijn.

Ook de actieve kernel moet aan voorwaarden voldoen. De integriteitsmodus van kernel-lockdown moet expliciet bij het opstarten zijn ingeschakeld. Die modus beperkt handelingen waarmee zelfs een proces met rootrechten de kernel zou kunnen wijzigen, zoals het laden van niet-ondertekende modules of het schrijven naar fysiek geheugen. Kexec moet bij het opstarten zijn uitgeschakeld, omdat daarmee een nieuwe kernel kan worden geladen zonder de gewone opstartketen opnieuw te doorlopen.

De BPF Linux Security Module moet geladen en actief zijn. Voor systemen die geen handheld zijn, moet bovendien de IOMMU in de firmware aanstaan en door de kernel worden gebruikt, met passthrough uitgeschakeld. Die voorziening begrenst de toegang van daarvoor geschikte apparaten tot het fysieke geheugen. De aangekondigde eisen vormen samen een controle van de configuratie waarin een spel start, niet slechts van de aanwezigheid van één schakelaar in het UEFI-menu.

Vertrouwde sleutels zijn nog geen distributielijst

De gepubliceerde lijst noemt onder meer sleutels van Canonical, Fedora, Universal Blue, Debian en openSUSE. Het gaat om sleutels voor de verificatie van de opstartketen en modules, niet om een lijst die elke installatie van die distributies als compatibel verklaart. Een pc met een herkende kernel kan nog op ontbrekende opstartmetingen, een andere kernelinstelling of een geladen module met een niet-herkende handtekening stranden.

Voor externe stuurprogramma’s is dat onderscheid concreet. NVIDIA’s GPU-stuurprogramma’s worden in de technische eisen genoemd als voorbeeld van modules die buiten de kernelbroncode worden onderhouden. In de discussie op r/linux wijzen gebruikers op de mogelijke gevolgen voor zelfondertekende modules en zulke stuurprogramma’s. Dat is een zorg over de sleutelregels, geen vastgesteld compatibiliteitsresultaat voor iedere installatie met een NVIDIA-kaart.

Een zelf beheerde Machine Owner Key vraagt extra aandacht. Bij gebruik van shim kunnen ingeschreven MOK’s doorgaans worden vertrouwd voor moduleverificatie, ook wanneer ze niet voor de gekozen opstartketen zijn gebruikt. Daarom moeten volgens de aangekondigde regels alle ingeschreven MOK’s bekend zijn. Andere eigen sleutels kunnen bij een aparte opstartoptie gebruikt blijven worden, maar de sessie waarin een beschermd spel draait moet aan de eisen voldoen.

Voor de Steam Deck ontbreken momenteel functies die deze uitvoering vereist. Er lopen gesprekken met Valve over toekomstige ondersteuning, maar die leveren nog geen toezegging over compatibiliteit op. Ook voor gewone distributies ontbreekt een afgeronde lijst van werkende combinaties van opstartmethode, kernel en stuurprogramma’s.

Welke onderdelen je nu kunt inventariseren

De eigen configuratie is wel al langs de aangekondigde eisen te leggen. Deze controlepunten brengen mogelijke knelpunten in beeld; ze voorspellen niet de uitkomst van de geplande Fortnite-proef.

Secure Boot en opstartsleutels: kijk of Secure Boot actief is, met welke sleutel de bootmanager en kernel worden geverifieerd en welke MOK’s zijn ingeschreven. Een ingeschakelde optie zonder zicht op de gebruikte sleutels geeft nog geen volledig beeld.
Kernel en modules: bepaal welke kernel tijdens het spelen werkelijk draait. Inventariseer geladen modules die buiten de distributiekernel zijn gebouwd, waaronder eventuele grafische stuurprogramma’s, en kijk welke ondertekenaar bij de modules hoort.
TPM en opstartmetingen: ga na of de TPM in de firmware beschikbaar en ingeschakeld is en of de bootmanager de opstartketen meet. Een aanwezige TPM en een gemeten opstartketen zijn afzonderlijke voorwaarden.
Kernelbeveiliging: controleer de actieve lockdown-modus, de instelling die kexec uitschakelt en of BPF LSM geladen is. Het gaat om de toestand van de kernel die bij het starten van het beschermde spel actief is.
IOMMU: controleer op een pc die geen handheld is zowel de firmware-instelling als het gebruik door de kernel. De aangekondigde eis sluit passthrough voor die configuratie uit.

De eerste concrete toets wordt de Fortnite-proef in een live spelomgeving. Daarna moet blijken welke configuraties voldoen en of de bescherming voldoende werkt om de nieuwe uitvoering aan meer gameontwikkelaars aan te bieden. Tot die tijd geeft de lijst met vertrouwde sleutels spelers een aanknopingspunt, maar nog geen uitsluitsel voor hun volledige systeem.