El error de coma de Cyrix es un defecto de diseño en los procesadores Cyrix 6x86 (introducido en 1996), 6x86L y los primeros 6x86MX que permite que un programa sin privilegios cuelgue la computadora.
Según Andrew Balsa, en la época en que se descubrió el error F00F en el Intel Pentium , Serguei Shtyliov de Moscú encontró un defecto en un procesador Cyrix mientras desarrollaba un controlador de disco IDE en lenguaje ensamblador . Alexandr Konosevich, de Omsk , investigó más a fondo el error y fue coautor de un artículo con Uwe Post en la revista de tecnología alemana c't , llamándolo "error CLI oculto" (CLI es la instrucción que desactiva las interrupciones en la arquitectura x86 ). Balsa, como miembro de la lista de correo del kernel de Linux , confirmó que el siguiente programa C (que utiliza un lenguaje ensamblador específico para x86 en línea ) podría ser compilado y ejecutado por un usuario sin privilegios :
carácter sin firmar c [ 4 ] = { 0x36 , 0x78 , 0x38 , 0x36 }; int main () { asm ( " movl $c, %ebx \n " "otra vez: xchgl (%ebx), %eax \n " " movl %eax, %edx \n " " jmp otra vez \n " ); } La ejecución de este programa inutiliza completamente el procesador hasta que se reinicia, ya que entra en un bucle infinito que no se puede interrumpir . Esto permite que cualquier usuario con acceso a un sistema Cyrix con este error realice un ataque de denegación de servicio .
Es similar a la ejecución de una instrucción Halt and Catch Fire , aunque el error de coma no es una instrucción en particular.
Lo que causa el error no es una máscara de interrupción , ni las interrupciones están deshabilitadas explícitamente. En cambio, una anomalía en la canalización de instrucciones de Cyrix impide que se atiendan las interrupciones durante la duración del ciclo; Dado que el ciclo nunca termina, las interrupciones nunca serán atendidas. La instrucción xchg [1] es atómica , lo que significa que otras instrucciones no pueden cambiar el estado del sistema mientras se ejecuta. Para garantizar esta atomicidad, los diseñadores de Cyrix hicieron que xchg fuera ininterrumpible. Sin embargo, debido a la canalización y la predicción de bifurcaciones , otro xchg ingresa a la canalización antes de que se complete el anterior, lo que provoca un punto muerto .
Una solución para casos no intencionados del error es insertar otra instrucción en el bucle, siendo la instrucción nop una buena candidata. Cyrix sugirió serializar el código de operación xchg, evitando así el proceso. Sin embargo, estas técnicas no servirán para prevenir ataques deliberados.
También se puede evitar el error deshabilitando el bloqueo implícito del bus que normalmente se realiza mediante la instrucción xchg . Esto se logra configurando el bit cuatro (máscara de 0x10) en el registro de configuración CCR1.