El trabajo de Aitor Menta (II)

Una vez ya sabemos un poco de terminología, podemos adentrarnos sin miedo alguno en los recovecos de la Informática. Sin miedo alguno, digo, puesto que Aitor no guiará con firme paso y aguerrido pulso entre bits y buses, sin temer a perros guardianes con relojes ni a astutos manejadores (handlers).

[La informática es fácil. No puede ser de otro modo puesto que estamos intentando que trastos carentes de alma imiten muchos procesos que el ser humano lleva haciendo desde hace milenios. Cuando un informático te diga que algo es difícil de explicar, o es mal informático, o te está mintiendo]

Pero a lo que íbamos: ¿qué se puede hacer para fastidiar un ordenador?. Como sabemos, dedicarnos a golpearlo puede ser una (atrayente) idea, pero no nos sirve como computer science. En su lugar, los informáticos suelen utilizar lo que llaman Técnicas de Inyección de Fallos. Aitor lo llama putea al procesador.

Una cosa debe quedar clara. El objetivo de todas estas técnicas no es que un sistema funcione a la perfección, es decir, libre de errores, fallos y averías. El objetivo es evaluar hasta que punto estos comprometen algo que llamaremos, pomposamente, Garantía de Funcionamiento. La Garantía de Funcionamiento viene a ser la confianza que otorgamos a un sistema en funcionamiento, es decir, una medida de hasta cuánto podemos depender de él. Esto depende de muchos factores, a los que también nombramos con malas traducciones del inglés. Uno de esos factores puede ser la disponibilidad. Un ejemplo: podemos tener un sistema que autentique usuarios legítimos de una Base de Datos supersecreta del Gobierno. Este sistema puede ser a prueba de TODO fallo e intrusión maligna... pero si sólo está en funcionamiento el 10% del tiempo, pocas veces depositaremos en él nuestra confianza a la hora de identificarnos como espías.

Los informáticos hablan de dos variables a estudiar: cobertura y tiempo de latencia. Llaman cobertura a la probabilidad de detectar un fallo en el sistema. El tiempo de latencia es el transcurrido entre la detección del fallo hasta completar los mecanismos que tome el sistema frente a este. Inyectando fallos (puteando al procesador) estudiaremos:

1. De qué manera afectan los distintos fallos al sistema, para poder diseñar una buena respuesta a estos.
2. Una vez en marcha los tratamientos escogidos, estudiaremos si las coberturas y tiempos de latencia obtenidos en sistemas puteados pueden comprometer la Garantía de Funcionamiento.

Técnicas de inyección de fallos

En primer lugar distinguimos entre fallos de verdad y de mentira. Los de verdad son de verdad. Los de mentira son fallos producidos en modelos de simulación. Es decir, de mentira. Lo de inyectar fallos en modelos de simulación queda genial para darse aires de sabidillo, pero en la realidad, es tan tonto como eliminar una linea del Paint que unía dos cajas. De hecho, suele ser eliminar una linea de un dibujo. Sólo que el dibujo representa un sistema programado con VHDL y el fallo simula una rotura de un cable. Se puede incluso programar para que falle a veces, lo cual no es mucho más complicado que seleccionar una opción del menú contextual. Los buenos programas de diseño deben estar hechos para tontos.

De entre los fallos de verdad distinguimos entre los de verdad y los de mentira. Los de verdad son los fallos hardware. Los de mentira pertenecen al mundo (imperecedero e incorruptible) del software.

Hay muchas y muy divertidas maneras de inyectar fallos HW sin utilizar martillos. Una muy utilizada consiste en destripar en lo posible el aparato y forzar niveles de tensión en los pines. Lo malo es que, como cada vez los componentes son más pequeños, esta técnica tiene un coste mayor y no podemos acceder a todos los sitios que desearíamos. Otra idea es someter al sistema a interferencias electromagnéticas (EMI), similares a las que encontrará en un entorno industrial hostil y malvado. Su problema es que apenas podemos decidir qué parte del sistema queremos afectar.

Otra más, y más chula, consiste en bombardear el sistema con pesados... iones de elementos radioactivos (como Californio 252). El problema es que nos es muy difícil reproducir varias veces el mismo experimento o fallo. Además, también es complicado precisar el componente o área a afectar. Para ello, podemos utilizar una radiación láser. En ambos casos, el coste de la infraestructura es considerable.

La inyección física presenta otro problema (marginal) que no hemos considerado: podemos cargarnos el bicho. Y no están las subvenciones en I+D+i como para romper coas alegremente.

Esa es una ventaja de la inyección software. Que normalmente no llegamos a cargarnos el sistema. Para quien no tenga ni papa de informática, diremos que un fallo SW es un fallo causado por un programa en ejecución. Hay un montón de clasificaciones de fallos SW, pero no es cuestión de ponernos pedagógicos. Según cuánto duran, por ejemplo. O según si producimos el error mientras se ejecuta o antes de cargar el código en el sistema.
Con los fallos SW podemos accecder de forma controlada y repetible a casi todos los componentes del sistema. Además podemos lograr un buen control del momento de inyección y entonces ponernos a medir el tiempo. Ejemplos de fallo SW: alterar la memoria de código para que el procesador se encuentre con instrucciones "chungas". Ejemplo 2, alterar los parámetros de las funciones del sistema. A los fallos SW es a lo que se está dedicando últimamente Aitor Menta.

¿Y todo esto para qué?

¿Y todo esto para qué?, digo yo. Pues porque los ingenieros quieren saber hasta qué punto puede fallar un sistema para poder ponerle un precio. He aquí lo que diferencia la ciencia más pura y nívea de la aceitosa ingeniería. Ingeniería no consiste en realizar sistemas perfectos... sino lo mejor posibles con unos recursos limitados.

Pregunta: ¿cuánto vale la vida de las personas que circulan en un cercanías?. Cualquier político dirá que no tiene precio. Pero lo tiene y se puede evaluar en relación a otros gastos. Si no se incorporan mecanismos de tolerancia a fallos a una vía porque el dinero se destina a acondicionar calles para circuitos de alta velocidad, entonces estamos considerando la seguridad de los viajeros del tren menos valiosa que los circuitos urbanos. Los ingenieros deben saber poner números al riesgo existente, usando conceptos como el de garantía de servicio, cobertura, fiabilidad... y luego calcular los costes.
Y posiblemente serán otros quienes decidan si merece la pena asumirlos.

Nota lectora: algunos dilemas como éste son abordados por Tim Harford en El Economista Camuflado.