Epic porta Easy Anti-Cheat V2 su Linux: Fortnite chiede Secure Boot e TPM

📌 In Sintesi

• Epic sta ricostruendo Easy Anti-Cheat come EAC Linux v2 e userà Fortnite come primo test prima di aprire la tecnologia agli altri sviluppatori.
• La nuova versione non utilizzerà un modulo anti-cheat nel kernel, ma richiederà kernel e moduli firmati, TPM 2.0, Secure Boot, measured boot, IOMMU, lockdown, kexec disabilitato e BPF LSM.
• Steam Deck non soddisfa oggi tutti i requisiti indicati da Epic: il nuovo anti-cheat riapre quindi il conflitto tra gaming competitivo e libertà di modificare la piattaforma Linux.

Fortnite arriverà su Linux, ma il prezzo tecnico richiesto da Epic per rendere possibile il gaming competitivo potrebbe trasformare una normale installazione Linux in un ambiente molto più controllato di quanto molti utenti siano abituati ad accettare. Epic Games ha presentato Easy Anti-Cheat Linux v2, una ricostruzione della propria infrastruttura anti-cheat progettata per avvicinare il livello di protezione offerto su Linux a quello disponibile su Windows. Il primo laboratorio sarà Fortnite, ancora non disponibile nativamente sulla piattaforma: una volta validato il sistema, Epic intende renderlo disponibile agli altri sviluppatori. La differenza più interessante è che EAC Linux v2 non installerà un proprio driver nel kernel. Utilizzerà invece gli strumenti di sicurezza già presenti in Linux, ma pretenderà che il sistema sia configurato secondo una catena di fiducia molto rigida.

Epic ammette che il vecchio Easy Anti-Cheat su Linux proteggeva meno di Windows

Nel documento tecnico ufficiale di Epic Online Services la società parte da un’ammissione importante. EAC supporta client Linux nativi dal 2014 e dal 2021 può funzionare anche con build Windows eseguite attraverso Wine e Proton, ma l’attivazione dipende dal singolo sviluppatore. Numerosi publisher hanno preferito non abilitarla perché, secondo Epic, l’implementazione Linux non garantiva lo stesso livello di protezione del sistema Windows. È anche la ragione indicata dalla società per spiegare perché Fortnite sia rimasto fuori da Linux. Il problema non è più semplicemente eseguire il gioco. Proton 11 ha ormai portato una quantità crescente di titoli Windows su Linux e Steam Deck, ma una compatibilità grafica e API perfetta non risolve il controllo dell’integrità richiesto dai multiplayer competitivi. Un gioco può funzionare tecnicamente sotto Proton e rimanere comunque inutilizzabile perché il server non considera affidabile il client.

Leggi anche: Nvidia, driver e Vulkan accelerano il gaming Linux

EAC V2 non installa un driver kernel ma pretende che Linux si chiuda da solo

Epic sceglie una strada diversa da quella adottata su Windows. EAC Linux v2 non caricherà un modulo anti-cheat nel kernel. La piattaforma utilizzerà invece Secure Boot, measured boot, TPM, kernel lockdown, IOMMU, BPF LSM ed eBPF per verificare che l’ambiente nel quale viene eseguito il gioco non sia stato modificato. La lista dei requisiti è precisa. Kernel e kernel module devono essere firmati attraverso chiavi riconosciute; TPM 2.0 deve essere disponibile; Secure Boot deve risultare attivo; il bootloader deve produrre misure verificabili; IOMMU deve essere abilitata con passthrough disattivato sui sistemi non handheld; il kernel deve funzionare in lockdown integrity mode; kexec deve essere disabilitato e il BPF Linux Security Module deve essere attivo. Epic utilizzerà inoltre programmi eBPF propri e un servizio systemd, avviato soltanto mentre gira un gioco protetto. Tecnicamente la scelta è interessante perché evita la presenza di un driver anti-cheat proprietario equivalente a quello utilizzato su Windows. Politicamente, però, sposta la stessa esigenza sul sistema operativo: non è Epic a inserire codice nel kernel, è Linux che deve presentarsi a Epic in una configurazione sufficientemente bloccata da essere considerata affidabile.

Root non deve più poter modificare tutto durante una partita

Il requisito più significativo è probabilmente il kernel lockdown. Linux nasce con un modello nel quale root rappresenta tradizionalmente il massimo livello di controllo locale. La modalità integrity riduce invece alcune possibilità anche per l’amministratore, bloccando operazioni che potrebbero modificare il kernel, accedere direttamente alla memoria fisica o caricare moduli non considerati affidabili. Da una prospettiva anti-cheat ha perfettamente senso: se l’utente può modificare liberamente il livello sul quale gira il sistema di verifica, il sistema di verifica non può fidarsi del risultato ottenuto. Da una prospettiva open source emerge però la frizione fondamentale. Il proprietario del computer deve volontariamente rinunciare a una parte del proprio controllo per dimostrare a un servizio remoto di non avere alterato il sistema. L’evoluzione del gaming Linux ha finora seguito la direzione opposta, aumentando la libertà di eseguire software nato per altre piattaforme attraverso Proton, DXVK e nuovi driver. EAC Linux v2 introduce una seconda traiettoria: maggiore compatibilità commerciale in cambio di un ambiente di esecuzione verificabile.

Anche i driver Nvidia devono entrare nella catena di fiducia

Il requisito della firma riguarda non soltanto il kernel ma anche i moduli esterni. Epic cita esplicitamente casi come i driver Nvidia, che su molte distribuzioni vengono caricati come componenti out-of-tree. Per essere compatibili con EAC v2 dovranno essere firmati attraverso una chiave riconosciuta dalla catena considerata affidabile. Epic mantiene per ora un elenco di autorità note che comprende Canonical, Fedora, Universal Blue, Debian, openSUSE, SUSE, Rocky Linux e la Microsoft UEFI CA, con l’obiettivo dichiarato di rendere successivamente open source la lista. La scelta rafforza inevitabilmente le distribuzioni maggiori e quelle che dispongono di una supply chain organizzata. Un kernel personalizzato, una configurazione sperimentale o un modulo compilato dall’utente possono invece richiedere un boot alternativo. Epic stessa suggerisce questa possibilità: l’utente può mantenere una configurazione separata dedicata ai giochi protetti, lasciando un secondo boot con kernel e chiavi personali per il resto dell’attività. Se il controllo fallisce, EAC dovrebbe impedire l’avvio del titolo protetto senza trasformare automaticamente il problema in un ban.

Steam Deck resta fuori proprio mentre Fortnite dovrebbe arrivare su Linux

Il paradosso più evidente riguarda Steam Deck. Epic afferma che l’hardware Valve non supporta oggi tutti i requisiti necessari al nuovo EAC v2, anche se sono in corso discussioni con Valve per cercare una soluzione. Questo significa che Fortnite può prepararsi a entrare ufficialmente su Linux senza poter essere immediatamente eseguito sulla macchina che ha contribuito più di qualsiasi altra a rendere visibile il gaming Linux. Il problema non è secondario. Steam Deck e SteamOS hanno costruito il proprio successo sull’equilibrio tra console e PC modificabile. Valve controlla l’immagine di sistema, ma l’utente può uscire dalla Game Mode, modificare il sistema e utilizzare software esterno. La crescita di SteamOS anche su nuovi handheld e piattaforme ARM rende questa libertà parte integrante della proposta Linux. EAC chiede invece una prova crittografica che il sistema non sia stato modificato in modi capaci di alterare il gioco.

Continua con:

Proton 11 amplia il catalogo Windows eseguibile su Linux e Steam Deck

Linux compie 35 anni tra open source, desktop e infrastrutture globali

Fortnite può aprire Linux ai multiplayer oppure trasformare l’apertura in un’eccezione

EAC Linux v2 potrebbe rimuovere uno degli ultimi grandi ostacoli alla crescita del gaming Linux. Se Fortnite dimostrerà che un multiplayer di enorme scala può funzionare senza rendere il cheating significativamente più semplice rispetto a Windows, altri publisher potrebbero finalmente abilitare titoli che oggi restano esclusi da Proton esclusivamente per ragioni anti-cheat. Il costo è però evidente. Per ottenere quel catalogo, Linux deve offrire alle società di gaming un ambiente nel quale kernel, moduli, boot chain e memoria possano essere attestati in modo affidabile. Epic prova a farlo senza replicare su Linux il proprio driver kernel Windows, una scelta tecnicamente meno invasiva. Ma il risultato resta filosoficamente complesso: per dimostrare di essere una piattaforma aperta abbastanza da eseguire qualsiasi gioco, Linux potrebbe dover diventare temporaneamente abbastanza chiuso da convincere quel gioco a fidarsi del sistema. Il successo di EAC Linux v2 dipenderà quindi meno dall’arrivo di Fortnite che dalla soluzione di questa contraddizione. Se Epic e le distribuzioni riusciranno a costruire una modalità protetta che l’utente può attivare senza perdere permanentemente il controllo della macchina, il progetto può aprire un mercato enorme. Se invece il gaming competitivo richiederà progressivamente kernel, driver e configurazioni approvati da una lista esterna, Linux avrà conquistato i giochi Windows rischiando di importare insieme a loro una parte del modello di fiducia chiuso che aveva sempre cercato di evitare.