stringtranslate.com

Detenerse y prender fuego (informática)

En ingeniería informática, Halt and Catch Fire , conocido por el acrónimo en lenguaje ensamblador HCF , es un modismo que hace referencia a una instrucción de código de máquina de computadora que hace que la unidad central de procesamiento (CPU) de la computadora deje de funcionar de manera significativa, lo que generalmente requiere un reinicio de la computadora. Originalmente se refería a una instrucción ficticia en las computadoras IBM System/360 (introducida en 1964), haciendo una broma sobre sus numerosos acrónimos de instrucciones no obvios.

Con la llegada del MC6800 (introducido en 1974), los programadores descubrieron un fallo de diseño. Debido a la decodificación incompleta del código de operación, dos códigos de operación ilegales , 0x9D y 0xDD, harán que el contador de programa en el procesador se incremente sin fin, lo que bloquea el procesador hasta que se restablezca. Esos códigos se han denominado extraoficialmente HCF. Durante el proceso de diseño del MC6802, los ingenieros originalmente planearon eliminar esta instrucción, pero la mantuvieron como estaba para fines de prueba. Como resultado, HCF fue reconocido oficialmente como una instrucción real. [1] [2] Más tarde, HCF se convirtió en un término humorístico que abarcaba todas las instrucciones que pueden congelar un procesador, incluidas las instrucciones intencionales para fines de prueba y las instrucciones ilegales no intencionales. Algunas se consideran defectos de hardware y, si el sistema es compartido , un usuario malintencionado puede ejecutarlas para lanzar un ataque de denegación de servicio .

En el caso de instrucciones reales, la implicación de esta expresión es que, mientras que en la mayoría de los casos en que una CPU ejecuta una instrucción no deseada (un error en el código) la computadora aún puede recuperarse, en el caso de una instrucción HCF, por definición, no hay forma de que el sistema se recupere sin reiniciar.

La expresión " prenderse fuego" es una exageración jocosa de la velocidad con la que el chip de la CPU conmutaría algunos circuitos de bus, provocando que se sobrecalienten y se quemen. [3]

Orígenes

Las computadoras Z1 (1938) y Z3 (1941) construidas por Konrad Zuse contenían secuencias ilegales de instrucciones que dañaban el hardware si se ejecutaban por accidente. [4]

Existen relatos apócrifos que vinculan este término con un código de operación ilegal en IBM System/360 . Un procesador, al encontrar la instrucción, comenzaría a cambiar las líneas de bus muy rápido, lo que podría provocar un sobrecalentamiento. [5] [6]

En el lenguaje ensamblador de un ordenador , se utilizan mnemotecnias que son directamente equivalentes a las instrucciones de código máquina . Las mnemotecnias suelen tener tres letras, como ADD, CMP (para comparar dos números) y JMP (saltar a una ubicación diferente en el programa). La instrucción HCF era originalmente una instrucción de lenguaje ensamblador ficticia, que se decía que estaba en desarrollo en IBM para su uso en sus ordenadores System/360 , junto con muchas otras siglas divertidas de tres letras como XPR (Execute Programmer) y CAI (Corrupt Accounting Information), y similar a otras mnemotecnias de broma como "SDI" para "Self Destruct Immediately" [7] y "CRN" para "Convert to Roman Numerals" [8] . Una lista de dichas mnemotecnias, incluida HCF, aparece como "Mnemónicas sobreextendidas" en la edición de parodia de Creative Computing de abril de 1980. [9]

En las CPU modernas

Los diseñadores de CPU a veces incorporan una o más instrucciones de código de máquina no documentadas para fines de prueba, como la instrucción DIAGnose del IBM System/360. [10]

Motorola 6800

El microprocesador Motorola 6800 fue el primero en el que se hizo ampliamente conocido un código de operación de ensamblaje no documentado (HCF). Los códigos de operación ( opcodes , las partes de las instrucciones en lenguaje de máquina que especifican una operación a realizar) hexadecimales 9D y DD fueron reportados y se les dio el código de operación no oficial (HCF) en un artículo de diciembre de 1977 de Gerry Wheeler en la revista BYTE sobre códigos de operación no documentados. [11] Wheeler notó que Motorola reportó 197 códigos de operación válidos para el procesador M6800, y por lo tanto dedujo que con 256 posibles combinaciones de 8 bits, debe haber 59 instrucciones no válidas. Describió el HCF como una "gran sorpresa", y dijo de la parte Catch Fire del apodo, "Bueno, casi":

Cuando se ejecuta esta instrucción, la única forma de ver lo que está haciendo es con un osciloscopio . Desde el punto de vista del usuario, la máquina se detiene y desafía la mayoría de los intentos de reiniciarla. Aquellas personas con luces indicadoras en el bus de direcciones verán que el procesador comienza a leer toda la memoria, secuencialmente, muy rápidamente. En efecto, el bus de direcciones se convierte en un contador de 16 bits. Sin embargo, el procesador no se da cuenta de lo que está leyendo... simplemente lee. [11]

Otro autor escribió en 2002:

En los viejos tiempos del microprocesador Motorola 6800, el código de instrucción DD hacía que el procesador entrara en un bucle infinito, leyendo cada dirección de memoria en orden. (Otros ingenieros se referían a esto como la instrucción "Halt and Catch Fire" [HCF], pero nosotros recordamos el código llamándolo instrucción "Drop Dead"). El modo Drop Dead era maravilloso para detectar problemas de lógica de direcciones y sincronización de hardware con un osciloscopio; todas las líneas de dirección y reloj eran ondas cuadradas agradables y cíclicas. [12]

El comportamiento del 6800 al encontrarse con HCF era conocido por Motorola en 1976. Cuando el 6800 encuentra la instrucción HCF, el procesador nunca encuentra el final de la misma, incrementando infinitamente su contador de programa hasta que se reinicia la CPU. [13] Por lo tanto, el bus de direcciones se convierte efectivamente en un contador , lo que permite verificar rápidamente el funcionamiento de todas las líneas de dirección . Una vez que el procesador entró en este modo, no responde a las interrupciones , por lo que el funcionamiento normal solo se puede restaurar mediante un reinicio (de ahí los apodos "Drop Dead" y "Halt and Catch Fire"). Estas referencias son, por lo tanto, al comportamiento insensible de la CPU en este estado, y no a ninguna forma de comportamiento errático. [ cita requerida ] . Motorola mantuvo el comportamiento HCF en la variante 6802 del procesador (que se lanzó en 1977) como una autoprueba intencional para los 128 bytes de RAM integrada del 6802.

Más tarde se encontraron otras instrucciones similares a HCF en el Motorola 6800 al ejecutar códigos de operación no documentados FD (con un ciclo dos veces más lento que 9D/DD) o CD/ED (con un ciclo a una frecuencia muy baja legible por humanos en un número limitado de líneas de dirección alta). [14]

Se cree que HCF es la primera función de autoprueba incorporada en un microprocesador Motorola. [2]

Intel x86

Los procesadores Intel 8086 y posteriores de la serie x86 tienen una instrucción HLT (halt), código de operación F4, que detiene la ejecución de la instrucción y coloca al procesador en un estado HALT. Una interrupción habilitada, una excepción de depuración, la señal BINIT, la señal INIT o la señal RESET reanudan la ejecución, lo que significa que el procesador siempre se puede reiniciar. [15] Algunos de los primeros chips Intel DX4 tienen un problema con la instrucción HLT y no se pueden reiniciar después de que se utiliza esta instrucción, lo que deshabilita la computadora y convierte a HLT en una instrucción HCF. El núcleo de Linux tiene una opción "no-hlt" que le dice a Linux que ejecute un bucle infinito en lugar de usar HLT, lo que permite a los usuarios de estos chips rotos usar Linux. [16]

El 80286 tiene el código de operación no documentado 0F 04, que hace que la CPU se bloquee cuando se ejecuta. La única salida es reiniciar la CPU. [ cita requerida ] [17] En algunas implementaciones, el código de operación se emula a través del BIOS como una secuencia de detención . [18]

Muchos ordenadores de la línea Intel Pentium pueden bloquearse al ejecutar una instrucción no válida (F00F C7C8), lo que hace que el ordenador se bloquee. Esto se conoce como el error Pentium F00F . Ningún compilador crea la instrucción, pero un programador malintencionado puede insertarla en el código para dejar inoperativo un ordenador afectado hasta que se apague y encienda la máquina . Desde su descubrimiento, se han desarrollado soluciones alternativas para evitar que bloquee el ordenador, y el error se ha eliminado en los procesadores Intel posteriores. [19] [20]

Durante Black Hat USA 2017 , Christopher Domas demostró que encontró una nueva instrucción "Halt and Catch Fire" [21] [22] en un modelo de procesador x86 no revelado usando su propio fuzzer de procesador x86 llamado sandsifter. [23]

Otras CPU

El NMOS MOS Technology 6502 tiene 12 instrucciones no válidas que hacen que el contador del programa no pueda obtener la siguiente instrucción, bloqueando la CPU y requiriendo un reinicio del procesador. [24] [25]   La versión WDC del CMOS 65C02 , así como el 65C816 , tiene la instrucción STP(stop, opcode ). Cuando se ejecuta, detendrá el reloj interno del procesador, lo que hará que cese todo el procesamiento; además, el procesador no responderá a todas las entradas excepto (reset). La única forma de borrar los efectos de una instrucción es alternar .$DBSTPRESBSTPRESB

En el Zilog Z80 , ejecutar DI (deshabilitar interrupciones) seguido de HALT (esperar una interrupción) hace que la CPU permanezca congelada indefinidamente, esperando una interrupción que no puede ocurrir. Sin embargo, la señal de interrupción no enmascarable se puede utilizar para salir de este estado, lo que hace que este par no sea un HCF verdadero. [26] [27] La ​​señal /NMI está en el pin 17 del paquete DIP original de 40 pines. [28] [29] El par solo dará como resultado una condición HCF si el pin /NMI está conectado directamente al riel de +5 V, lo que hace imposible la generación de esa señal, o si la rutina de interrupción que da servicio a /NMI termina con un retorno, colocándolo nuevamente en el estado HALT.

El núcleo del procesador SM83 [a] [30] en el sistema en chip LR35902 de Game Boy tiene un problema similar, provocado por dos HALT consecutivos con interrupciones deshabilitadas. [b] [31] El núcleo en sí contiene 11 códigos de operación que bloquean completamente la CPU cuando se ejecutan. [32]

El Hitachi SC61860, utilizado principalmente en computadoras de bolsillo Sharp en las décadas de 1980 y 1990, tiene una instrucción HCF no documentada con el código de operación 7B. [33]

Véase también

Notas

  1. ^ La CPU SM83 es ​​similar a la Z80, pero no está directamente relacionada.
  2. ^ Cuando las interrupciones están deshabilitadas, la instrucción HALT en la CPU de Game Boy no pausa la CPU, sino que, en cambio, evita que el contador de programa de la CPU se incremente en la instrucción inmediatamente posterior a HALT, duplicando efectivamente la instrucción después de HALT (o, para una instrucción de varios bytes, duplicando el primer byte y separando el último byte original en una nueva instrucción de un solo byte); si la instrucción después de HALT es en sí misma un HALT, entonces (como HALT es una instrucción de un solo byte) la CPU ve efectivamente una serie infinita de HALT, lo que hace que el sistema se bloquee.

Referencias

  1. ^ "Conjunto de instrucciones 6800" (PDF) . Bryan's Old Computers . Archivado (PDF) del original el 2021-05-01 . Consultado el 2022-04-09 .
  2. ^ ab Daniels, R. Gary; Bruce, William (abril de 1985). "Tendencias de autoprueba incorporada en microprocesadores Motorola". IEEE Design & Test . 2 (2): 64–71. doi :10.1109/MDT.1985.294865. S2CID  22719798. Para colmo de males, descubrimos que teníamos un HACOF ilegal, una instrucción que nuestros clientes encontraron en el MC6800. Era un código de operación no utilizado, una instrucción ilegal. Cuando se ejecutaba inadvertidamente, el contador del programa se incrementaba indefinidamente. El problema, que fue causado por una decodificación incompleta del código de operación, era una molestia porque Reset era el único medio de terminar la instrucción. ... Durante el proceso de diseño, descubrimos cómo eliminar la instrucción HACOF. En ese momento, los ingenieros de producto vinieron a nosotros con una idea. Dijeron: "¿Sabes lo que realmente nos gustaría? Alguna manera de probar rápidamente la RAM. Si pudiéramos apuntar el contador del programa a la primera dirección de RAM y luego simplemente incrementar la RAM, podríamos probarlo mucho más rápido. Como la "instrucción" HACOF hacía precisamente eso (y realmente no queríamos invertir el esfuerzo necesario para eliminarla), respondimos: "¡Tenemos un trato para ti!". HACOF se convirtió así en la primera función de autoprueba incorporada intencionalmente en un microprocesador Motorola.
  3. ^ "Entrada del archivo de jerga para el código mnemotécnico del ensamblado HCF". Archivado desde el original el 20 de mayo de 2012. Consultado el 4 de mayo de 2014 .
  4. ^ Rojas, Raúl (abril-junio de 1997). "El legado de Konrad Zuse: la arquitectura del Z1 y el Z3" (PDF) . IEEE Annals of the History of Computing . 19 (2): 5–16 [9–10]. doi :10.1109/85.586067. Archivado (PDF) desde el original el 2022-07-03 . Consultado el 2022-07-03 . p. 10: Hay muchos detalles que el ingeniero que diseña el "microprograma" debe tener en cuenta, de lo contrario los cortocircuitos pueden destruir el hardware. El Z1 con su diseño mecánico era aún más sensible en este aspecto que el Z3 . Incluso después de completarlo, había secuencias de instrucciones que el programador tenía que evitar para no dañar el hardware. Una de estas secuencias fue probada inadvertidamente en el Museo de Tecnología y Transporte de Berlín , lo que provocó daños leves en el Z1 reconstruido en 1994.(12 páginas)
  5. ^ Clements, Alan (28 de octubre de 2006). Incorporación de la ética en la arquitectura informática. Conferencia ASEE/IEEE Frontiers in Education (36.ª ed.). pág. 4. Archivado desde el original el 30 de abril de 2022. Consultado el 2 de marzo de 2018 .
  6. ^ Kohler, Eddie (4 de abril de 2005). "CS111 - Lección 1" (PDF) . pág. 2. Archivado (PDF) desde el original el 2 de marzo de 2018. Consultado el 2 de marzo de 2018 .
  7. ^ Dunlap, Bryan. "Un conjunto de instrucciones propuesto". Departamento de Física, Universidad Estatal de Ohio . Archivado desde el original el 8 de septiembre de 2017. Consultado el 20 de junio de 2016 .
  8. ^ Cirsovius, Werner. "Códigos operativos muy extravagantes". Archivado desde el original el 5 de marzo de 2016. Consultado el 28 de mayo de 2015 .
  9. ^ "Mnemónicos sobreextendido". Creative Computing . 6 (4): 17 (hex) (flip–side). Abril de 1980 . Consultado el 12 de marzo de 2017 .
  10. ^ Principios de funcionamiento del IBM System/360 (PDF) . IBM . Archivado (PDF) desde el original el 29 de febrero de 2012 . Consultado el 2 de julio de 2014 .
  11. ^ ab Wheeler, Gerry (diciembre de 1977). "Instrucciones M6800 no documentadas". BYTE . Vol. 2, no. 12. págs. 46–47 . Consultado el 20 de noviembre de 2023 . Por supuesto, los mnemónicos los asigné yo.
  12. ^ Agans, David J. (2002). Depuración: las 9 reglas indispensables para encontrar incluso los problemas de software y hardware más difíciles de detectar. Nueva York, EE. UU.: American Management Association. p. 77. ISBN 978-0-81442678-4. OCLC  52043345. Archivado desde el original el 26 de julio de 2014. Consultado el 30 de octubre de 2016 .
  13. ^ Daniels, R. Gary; Bruce, William (abril de 1985). "Tendencias de autoprueba incorporada en microprocesadores Motorola". IEEE Design & Test of Computers . 2 (2): 64. doi :10.1109/MDT.1985.294865. S2CID  22719798 . Consultado el 28 de agosto de 2023 .
  14. ^ Demeulemeester, Samuel (17 de julio de 2019). "Investigación de la instrucción HCF (Halt & Catch Fire) en Motorola 6800". X86.FR – Laboratorio de investigación y desarrollo de Doc TB . Archivado desde el original el 31 de marzo de 2022. Consultado el 9 de abril de 2022 .
  15. ^ "Referencia del conjunto de instrucciones x86: HLT". Archivado desde el original el 14 de julio de 2014. Consultado el 2 de julio de 2014 .
  16. ^ Gortmaker, Paul (21 de marzo de 2003). "El indicador de arranque de Linux: cómo hacerlo" (PDF) . The Linux Documentation Project. Archivado (PDF) desde el original el 6 de julio de 2015. Consultado el 2 de julio de 2014 .
  17. ^ "Re: Códigos de operación no documentados (HINT_NOP)". Archivado desde el original el 6 de noviembre de 2004. Consultado el 7 de noviembre de 2010 .
  18. ^ "Re: También algunos códigos de operación 0Fh no documentados". Archivado desde el original el 26 de junio de 2003. Consultado el 7 de noviembre de 2010 .
  19. ^ Collins, Robert R. (1 de mayo de 1998). "El error F00F de Pentium: soluciones alternativas para un problema desagradable". Diario del Dr. Dobb . Archivado desde el original el 30 de abril de 2022. Consultado el 12 de agosto de 2014 .
  20. ^ Actualización de especificaciones del procesador Pentium (PDF) . Intel Corporation . Enero de 1999. págs. 51–52. Número de pedido 242480-041. Archivado (PDF) desde el original el 4 de marzo de 2016 . Consultado el 2 de noviembre de 2006 .
  21. ^ "Rompiendo la ISA x86 (PDF)" (PDF) . Christopher Domas. Archivado (PDF) del original el 2018-01-04 . Consultado el 2017-12-09 .
  22. ^ "Rompiendo la ISA x86 (video)". Christopher Domas. 2017-08-31. Archivado desde el original el 2021-12-21 . Consultado el 2017-12-09 .
  23. ^ "sandsifter: el analizador de errores del procesador x86". Christopher Domas. Archivado desde el original el 25 de octubre de 2017. Consultado el 9 de diciembre de 2017 .
  24. ^ Steil, Michael. "Cómo funcionan realmente los códigos de operación ilegales de MOS 6502". pagetable.com . Archivado desde el original el 7 de julio de 2016. Consultado el 1 de agosto de 2016 .
  25. ^ Offenga, Freddy. «6502 Códigos de operación no documentados». NesDev . Archivado desde el original el 8 de agosto de 2016. Consultado el 1 de agosto de 2016 .
  26. ^ "Mecanismo de interrupción - Desarrollo - SMS Power!". Archivado desde el original el 4 de abril de 2016. Consultado el 25 de abril de 2016 .
  27. ^ Flammenkamp, ​​Achim. "Comportamiento de interrupción de la CPU Z80". Archivado desde el original el 20 de abril de 2016. Consultado el 25 de abril de 2016 .
  28. ^ "Pinouts - Familia Z80". Archivado desde el original el 8 de mayo de 2016. Consultado el 25 de abril de 2016 .
  29. ^ Vis, Peter J. "Zilog Z80 Pinout". Archivado desde el original el 11 de octubre de 2016. Consultado el 25 de abril de 2016 .
  30. ^ "Ingeniería inversa de la CPU de Game Boy SM83". GitHub . Archivado desde el original el 2022-10-29 . Consultado el 2022-11-08 .
  31. ^ "Manual de la CPU de GameBoy" (PDF) . Archivado (PDF) del original el 23 de junio de 2018 . Consultado el 22 de junio de 2018 .
  32. ^ "Conjunto de instrucciones de la CPU de Game Boy". Archivado desde el original el 9 de febrero de 2021. Consultado el 11 de marzo de 2021 .
  33. ^ "Conjunto de instrucciones SC61860 (también conocido como ESR-H)". GitHub . 2022-03-20. Archivado desde el original el 2022-03-23 ​​. Consultado el 2022-03-23 ​​.