Por qué los anticheat de nivel de kernel no existen en Linux

La pregunta parece sencilla: Linux tiene módulos de kernel, Windows tiene drivers, ambos corren en Ring 0. ¿Por qué no puedes simplemente portar Vanguard y listo? La respuesta corta es que el mecanismo existe pero el modelo de confianza en el que se apoya un anticheat de nivel kernel en Windows no tiene equivalente funcional en Linux. Y eso lo cambia todo.

Para entenderlo bien hay que rascar un poco por debajo del concepto de «driver».

#Ring 0 y la guerra de privilegios

Los procesadores x86 operan en anillos de privilegio. Ring 3 es donde viven los procesos normales: tu navegador, el juego, el cliente de Steam. Tienen acceso restringido a la memoria y al hardware. Ring 0 es el kernel: acceso total, sin filtros, sin barreras. Un bug en Ring 0 no te da pantalla azul en el mejor caso; en el peor, un atacante lo usa para leer lo que le venga en gana de la RAM.

Los anticheat de kernel — Vanguard de Riot, Ricochet de Activision — se instalan como drivers que arrancan en Ring 0 desde el inicio del sistema. Desde ahí pueden interceptar llamadas al sistema, escanear la memoria de otros procesos e inspeccionar si alguien ha metido mano en las estructuras internas del kernel. Si un cheat intenta ocultar un proceso o hookear una función del sistema, el anticheat lo ve porque opera al mismo nivel de privilegio o por encima.

En Linux existe exactamente el mismo modelo. Los módulos de kernel (archivos .ko) son el equivalente a los archivos .sys de Windows. Se cargan en Ring 0, tienen acceso completo al hardware y pueden registrar hooks en funciones del kernel. Técnicamente, nadie te impide escribir un anticheat como módulo de kernel para Linux.

El problema no es técnico. Es de arquitectura y de confianza.

#El modelo de confianza que lo rompe todo

Un anticheat de kernel funciona sobre un supuesto implícito: que el anticheat es la entidad más privilegiada del sistema y que puede verificar la integridad de todo lo demás. En Windows, Microsoft hace posible ese supuesto mediante el Driver Signature Enforcement (DSE).

El DSE exige que todo driver que quiera ejecutarse en Ring 0 esté firmado digitalmente por una autoridad reconocida por Microsoft. Si el driver no tiene firma válida, el kernel de Windows se niega a cargarlo. Esto crea una cadena de confianza: Microsoft certifica al fabricante del anticheat, el anticheat se instala como driver firmado, y el sistema garantiza que nadie ha metido código arbitrario en el kernel por detrás.

En Linux ese pilar no existe de la misma forma. El kernel sí tiene un sistema de firma de módulos (CONFIG_MODULE_SIG), y con Secure Boot activo puede rechazar módulos sin firma. Pero aquí está la trampa: el usuario puede generar sus propias claves, firmar sus propios módulos y registrar esa clave en el firmware como trusted. No necesita que nadie externo le autorice nada.

Y si no quiere ni molestarse con eso, puede simplemente recompilar el kernel desactivando la verificación de firmas. O arrancar con un kernel personalizado que devuelva los valores que le dé la gana a cualquier función que el anticheat consulte. El sistema operativo es código fuente público. El anticheat no puede asumir que el kernel que tiene debajo es el kernel que cree que es.

«Si no puedes garantizar un entorno bloqueado, un anticheat de kernel no ofrece ninguna ventaja de seguridad significativa sobre uno de modo usuario, pero sí introduce riesgos masivos de privacidad e inestabilidad del sistema.»

#El problema de la ABI inestable

Hay un segundo muro, más prosaico pero igual de alto. El kernel de Linux tiene una política deliberada: no garantiza una ABI estable entre versiones.

En Windows, un driver compilado para Windows 10 carga sin problemas en Windows 11. La interfaz binaria entre el kernel y los módulos se mantiene estable durante años — en algunos casos, décadas. Los equipos de anticheat en Windows escriben un driver, lo certifican, y lo olvidan durante meses.

En Linux, las estructuras internas del kernel, las firmas de funciones y los símbolos exportados cambian entre versiones sin aviso previo. Un módulo compilado para el kernel 6.8 puede no cargar en el 6.9. No es un bug; es política explícita del proyecto, documentada en el propio árbol de fuentes. La razón de fondo es sana — permite que el kernel evolucione sin arrastrar deuda técnica — pero para un equipo de anticheat supone un problema operacional considerable.

Imagina el pipeline de calidad: compilar el módulo, testearlo en Arch con kernel 6.12, en Ubuntu 24.04 LTS con su kernel parcheado, en Fedora 42, en el SteamOS de la Steam Deck con su fork propio… y repetir el ciclo cada vez que sale un kernel nuevo, que en Linux ocurre cada pocas semanas. Para un estudio con tres ingenieros dedicados al anticheat en Windows, abrir esa frente en Linux es sencillamente un presupuesto que no existe.

#El problema de Proton y la cadena de verificación

Hay una tercera capa de complejidad que muchos pasan por alto: la mayoría de usuarios Linux no ejecutan juegos de forma nativa. Los ejecutan a través de Proton, la capa de compatibilidad de Valve que traduce llamadas de DirectX a Vulkan y las llamadas de la API de Windows a equivalentes Linux.

Desde la perspectiva del anticheat, el juego no corre sobre un sistema operativo. Corre dentro de Wine, que emula el entorno de proceso de Windows por encima de Linux. La cadena de verificación que un anticheat intenta establecer — «¿es este proceso limpio, está la memoria intacta, no hay hooks extraños?» — se vuelve extraordinariamente difícil de garantizar cuando el propio entorno de ejecución es una capa de emulación.

Esto no es especulación: es exactamente por qué Apex Legends y Fortnite siguen bloqueados en Linux pese a que Easy Anti-Cheat técnicamente tiene soporte para Proton. Electronic Arts y Epic Games han optado por no activarlo. La decisión no es técnica en el sentido de «es imposible»; es una valoración de riesgo: no confían en que el modelo de verificación a través de Proton sea suficientemente robusto para sus juegos competitivos.

#Lo que sí funciona, y por qué

El panorama no es tan desolador como parece a primera vista.

Easy Anti-Cheat y BattlEye tienen soporte nativo para Linux y Proton desde 2021. El proceso para un estudio es activarlo mediante un toggle en sus respectivos portales de administración — literalmente cambiar un flag. El resultado es un anticheat que opera en modo usuario, con menos capacidad de detección que su contraparte de kernel, pero funcional para la mayoría de títulos no hipercompetitivos.

El problema es que ese soporte es enteramente opt-in. Nadie obliga al estudio a activarlo. Y muchos simplemente no lo hacen, ya sea por política corporativa, por riesgo percibido, o porque el porcentaje de su base de usuarios en Linux no justifica el trabajo de validación y soporte.

#El futuro: Remote Attestation y TPM

Existe una solución técnica al problema del modelo de confianza: la atestación remota. Con un chip TPM (Trusted Platform Module), el hardware puede generar una prueba criptográfica de que el sistema arrancó con un bootloader concreto, con un kernel concreto, sin modificaciones. El servidor de juego puede verificar esa prueba antes de permitir la conexión.

Es la misma tecnología que usa Google en Chromebooks, o Microsoft con el lanzamiento de Windows 11 como excusa para exigir TPM 2.0. En teoría, un anticheat que exigiera atestación remota podría funcionar en Linux sin necesidad de un driver de kernel, porque el propio hardware garantizaría la integridad del entorno.

La infraestructura existe. Los TPMs están en casi cualquier ordenador fabricado desde 2016. El problema es que implementarlo requiere que los estudios inviertan en la infraestructura de verificación en el lado servidor, coordinarse con los fabricantes de hardware, y gestionar el rechazo de usuarios con hardware más antiguo. Es un trabajo de varios años. No es lo que ningún estudio priorizará mientras Linux represente alrededor del 3-5% de la base de Steam según las encuestas de hardware de finales de 2025 y principios de 2026.

Esto lo escribo en julio de 2026 con un ecosistema Linux gaming que ha crecido notablemente gracias al Steam Deck. Si el porcentaje sigue subiendo, la ecuación económica de soportar Linux correctamente puede cambiar. Por ahora, la respuesta a «¿por qué no hay anticheat de kernel en Linux?» sigue siendo: porque no merece la pena el esfuerzo dado que el modelo de confianza no puede garantizarse sin reformar la forma en que el sistema operativo funciona, y eso nadie lo va a hacer por un 5% del mercado.