El error de coma de Cyrix es una falla de diseño en los procesadores Cyrix 6x86 (introducido en 1996), 6x86L y 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 Intel Pentium , Serguei Shtyliov, de Moscú, encontró un fallo 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 coescribió un artículo con Uwe Post en la revista tecnológica alemana c't , llamándolo el "error oculto de CLI" (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 en C (que utiliza lenguaje ensamblador específico de x86 en línea ) podría ser compilado y ejecutado por un usuario sin privilegios :
unsigned char 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 deja al procesador completamente inutilizable 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 ninguna instrucción en particular.
Lo que causa el error no es una máscara de interrupción , ni tampoco que las interrupciones se deshabiliten explícitamente. En cambio, una anomalía en la secuencia de instrucciones de Cyrix impide que se atiendan las interrupciones durante la duración del bucle; dado que el bucle nunca termina, las interrupciones nunca se atenderán. La instrucción xchg [1] es atómica , lo que significa que no se permite que otras instrucciones cambien 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 segmentación y la predicción de ramificaciones , otro xchg ingresa a la secuencia antes de que se complete el anterior, lo que causa un bloqueo .
Una solución para los casos no intencionales 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 desactivando el bloqueo de bus implícito que normalmente realiza la instrucción xchg . Esto se logra configurando el bit cuatro (máscara de 0x10) en el registro de configuración, CCR1.