El error de coma Cyrix es un defecto de diseño en Cyrix 6x86 (introducido en 1996), 6x86L , y los primeros 6x86MX procesadores que permite que un no privilegiado programa para colgar el equipo.
Descubrimiento
Según Andrew Balsa, en el momento del descubrimiento del error F00F en Intel Pentium , Serguei Shtyliov de Moscú encontró una falla en un procesador Cyrix mientras desarrollaba un controlador de disco IDE en lenguaje ensamblador . Alexandr Konosevich, de Omsk , investigó más el error y fue coautor de un artículo con Uwe Post en la revista de tecnología alemana c't , llamándolo el "error CLI oculto" (CLI es la instrucción que deshabilita las interrupciones en la arquitectura x86 ). Balsa, como miembro de la lista de correo del núcleo de Linux , confirmó que el siguiente programa C (que usa un lenguaje ensamblador específico de x86 en línea ) podría ser compilado y ejecutado por un usuario sin privilegios :
carácter sin signo c [ 4 ] = { 0x36 , 0x78 , 0x38 , 0x36 }; int main () { asm ( "movl $ c,% ebx \ n " "nuevamente: xchgl (% ebx),% eax \ n " "movl% eax,% edx \ n " "jmp nuevamente \ 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.
Análisis
Lo que causa el error no es una máscara de interrupción , ni las interrupciones están explícitamente deshabilitadas. En cambio, una anomalía en la canalización de instrucciones de Cyrix evita que las interrupciones sean atendidas durante el 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 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 el xchg fuera ininterrumpido. Sin embargo, debido a la predicción de la canalización y la ramificación , otro xchg entra en la canalización antes de que se complete la anterior, lo que provoca un punto muerto .
Soluciones alternativas
Una solución para instancias 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í la canalización. Sin embargo, estas técnicas no servirán para prevenir ataques deliberados.
Una forma de evitar este error es habilitar el bit 0x10 en el registro de configuración CCR1. Esto deshabilita el bloqueo de bus implícito que normalmente realiza la instrucción xchg . Dado que las CPU afectadas por este error no fueron diseñadas para funcionar en sistemas multiprocesador, la pérdida de atomicidad xchg es inofensiva. [ cita requerida ]
Ver también
Notas
enlaces externos
- La descripción temprana de Andrew Balsa del error
- Registros Cx6x86 (y características no documentadas)