Español | English
rss facebook linkedin Twitter

Bugs de silicio

Una anécdota muy conocida es la de la polilla que hacía fallar un relé en uno de los grandes ordenadores de los años 50. El término “bug” ya se utilizaba para referirse a errores o comportamientos no esperados en ingeniería y esta polilla se considera como el primer bug (en sentido literal y figurado) encontrado en un procesador.


Hasta ahora, los procesadores siempre han tenido errores. Diseñar e implementar un procesador es cada vez más complicado, supone más lineas de código y lógicamente más bugs. Algunos adquieren cierta fama, como el famoso FDIV de los primeros Pentium, pero normalmente pasan desapercibidos. Existen muchos más documentados de los que en principio se pueda pensar, tanto en procesadores Intel (Core duo y Core solo, Septiembre 2007) como AMD (Athlon64 y Opteron, Octubre 2007) .

Lo cierto es que la gran mayoría de estos errores se hacen notar en muy raras ocasiones y sus efectos suelen provocar que el procesador se pare, genere interrupciones que no deberían ocurrir o empeore el rendimiento. Es molesto, pero no supone un riesgo desde el punto de vista de la seguridad. Al menos de momento. En los últimos procesadores hay varios bugs que sí podrían suponer un riesgo para la seguridad, como flags de permisos de escritura o ejecución que son ignoradas o incluso intrucciones RET que en ciertas condiciones saltan a una dirección de memoria incorrecta.

Hoy en día estamos acostumbrados a aplicar parches a nuestro software y es algo que se realiza de una manera cada vez más automatizada. En el caso del hardware, hay varias posibles soluciones. Como consecuencia del bug FDIV, Intel cambió los procesadores defectuosos. Lógicamente, esta no es una solución práctica. En la actualidad, parte del código de los sistemas operativos se dedica a corregir en software los errores de los procesadores. Basta buscar las palabras quirk, workaround o errata en la carpeta arch del código de Linux.

Otra forma de combatir estos errores es que esa mayor complejidad de los procesadores ha traído también la posibilidad de actualizar su microcódigo, que define las instrucciones internas del procesador y que son distintas a las de la arquitectura x86. De cara al usuario esto se traduce normalmente en una actualización de la BIOS. Esta última solución pueden ser un poco engorrosa. La tendencia es utilizar actualizaciones del microcódigo que se envían al procesador durante el arranque del sistema operativo. Microsoft ya ha publicado un parche de este tipo, mientras que en Linux 2.6.20+ hay una aplicación llamada microcode_ctl que permite cargar descripciones del microcódigo que suministra Intel en su página web (ejemplo).

Parece que vamos a tener que acostumbrarnos a actualizar nuestro procesador, aunque sin duda, lo que deberían hacer los fabricantes es prestar más importancia a la seguridad del hardware, antes de que se descubra una vulnerabilidad aprovechable. Ahorraría muchos problemas y mucha publicidad negativa para la empresa afectada.

Patxi Astiz
S21sec labs

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login