stringtranslate.com

Inyección de fallas

En informática , la inyección de fallos es una técnica de prueba para comprender cómo se comportan los sistemas informáticos cuando se someten a tensiones inusuales. Esto se puede lograr utilizando medios físicos o basados ​​en software, o utilizando un enfoque híbrido. [1] Las inyecciones de fallos físicos ampliamente estudiadas incluyen la aplicación de altos voltajes, temperaturas extremas y pulsos electromagnéticos en componentes electrónicos, como la memoria de la computadora y las unidades centrales de procesamiento . [2] [3] Al exponer los componentes a condiciones más allá de sus límites operativos previstos, los sistemas informáticos pueden verse obligados a ejecutar instrucciones incorrectas y corromper datos críticos.

En las pruebas de software , la inyección de fallos es una técnica para mejorar la cobertura de una prueba mediante la introducción de fallos en las rutas de código de prueba; en particular, las rutas de código de manejo de errores , que de otro modo rara vez se seguirían. A menudo se utiliza con pruebas de estrés y se considera ampliamente que es una parte importante del desarrollo de software robusto . [4] Las pruebas de robustez [5] (también conocidas como pruebas de sintaxis, fuzzing o pruebas fuzz ) son un tipo de inyección de fallos que se utiliza comúnmente para probar vulnerabilidades en interfaces de comunicación como protocolos, parámetros de línea de comandos o API.

La propagación de una falla hasta convertirse en una falla observable sigue un ciclo bien definido. Cuando se ejecuta, una falla puede causar un error, que es un estado no válido dentro de los límites del sistema. Un error puede causar más errores dentro de los límites del sistema, por lo tanto, cada nuevo error actúa como una falla, o puede propagarse a los límites del sistema y ser observable. Cuando se observan estados de error en los límites del sistema, se denominan fallas. Este mecanismo se denomina ciclo falla-error-falla [6] y es un mecanismo clave en la confiabilidad .

Historia

La técnica de inyección de fallos se remonta a la década de 1970 [7] , cuando se utilizó por primera vez para inducir fallos a nivel de hardware. Este tipo de inyección de fallos se denomina Inyección de fallos implementada en hardware (HWIFI) e intenta simular fallos de hardware dentro de un sistema. Los primeros experimentos con fallos de hardware implicaban nada más que cortocircuitar las conexiones en las placas de circuitos y observar el efecto en el sistema (puentear fallos). Se utilizó principalmente como prueba de la fiabilidad del sistema de hardware. Más tarde se desarrolló hardware especializado para ampliar esta técnica, como dispositivos para bombardear áreas específicas de una placa de circuitos con radiación intensa. Pronto se descubrió que los fallos podían inducirse mediante técnicas de software y que aspectos de esta técnica podían ser útiles para evaluar sistemas de software. En conjunto, estas técnicas se conocen como Inyección de fallos implementada en software (SWIFI).

Inyección de fallas implementada por software

Las técnicas SWIFI se pueden clasificar en dos tipos: inyección en tiempo de compilación e inyección en tiempo de ejecución.

La inyección en tiempo de compilación es una técnica de inyección en la que se modifica el código fuente para inyectar fallas simuladas en un sistema. Un método se denomina prueba de mutación , que modifica las líneas de código existentes para que contengan fallas. Un ejemplo simple de esta técnica podría ser cambiar a = a + 1aa = a – 1

La mutación del código produce fallas muy similares a las que los programadores agregan involuntariamente.

Un refinamiento de la mutación de código es la inyección de errores de inserción de código , que agrega código en lugar de modificar el código existente. Esto se hace generalmente mediante el uso de funciones de perturbación, que son funciones simples que toman un valor existente y lo perturban mediante cierta lógica para convertirlo en otro valor, por ejemplo

 int pFunc ( int valor ) { valor de retorno + 20 ; }         int main ( int argc , char * argv []) { int a = pFunc ( aFunction ( atoi ( argv [ 1 ]))); if ( a > 20 ) { /* hacer algo */ } else { /* hacer algo más */ } }

En este caso, pFunc es la función de perturbación y se aplica al valor de retorno de la función que se ha llamado introduciendo un fallo en el sistema.

Las técnicas de inyección en tiempo de ejecución utilizan un disparador de software para inyectar una falla en un sistema de software en ejecución. Las fallas se pueden inyectar a través de varios métodos físicos y los disparadores se pueden implementar de varias maneras, como: disparadores basados ​​en tiempo (cuando el temporizador alcanza un tiempo específico, se genera una interrupción y el controlador de interrupciones asociado con el temporizador puede inyectar la falla); disparadores basados ​​en interrupciones (se utilizan excepciones de hardware y mecanismos de trampa de software para generar una interrupción en un lugar específico en el código del sistema o en un evento particular dentro del sistema, por ejemplo, el acceso a una ubicación de memoria específica).

Las técnicas de inyección en tiempo de ejecución pueden utilizar varias técnicas diferentes para insertar fallas en un sistema a través de un disparador.

Estas técnicas a menudo se basan en las facilidades de depuración que ofrecen las arquitecturas de procesadores de computadora.

Inyección de fallos en el software de protocolo

Los sistemas de software complejos, especialmente los sistemas distribuidos de múltiples proveedores basados ​​en estándares abiertos, realizan operaciones de entrada/salida para intercambiar datos a través de intercambios estructurados y con estado, conocidos como " protocolos ". Un tipo de inyección de fallas que es particularmente útil para probar implementaciones de protocolos (un tipo de código de software que tiene la característica inusual de que no puede predecir ni controlar su entrada) es el fuzzing . El fuzzing es una forma especialmente útil de prueba de caja negra , ya que las diversas entradas no válidas que se envían al sistema de software no dependen de los detalles del código que se ejecuta dentro del sistema y no se crean en función del conocimiento de estos.

Inyección de fallas implementada por hardware

Esta técnica se aplicó en un prototipo de hardware. Los probadores inyectan fallas al cambiar el voltaje de algunas partes de un circuito, aumentar o disminuir la temperatura, bombardear la placa con radiación de alta energía, etc.

Características de la inyección de fallas

Las fallas tienen tres parámetros principales. [8]

Estos parámetros crean el ámbito del espacio de fallas. El ámbito del espacio de fallas aumentará exponencialmente al aumentar la complejidad del sistema. Por lo tanto, el método tradicional de inyección de fallas no será aplicable para su uso en los sistemas ciberfísicos modernos, porque serán muy lentos y encontrarán una pequeña cantidad de fallas (menor cobertura de fallas). Por lo tanto, los evaluadores necesitan un algoritmo eficiente para elegir fallas críticas que tengan un mayor impacto en el comportamiento del sistema. Por lo tanto, la principal pregunta de investigación es cómo encontrar fallas críticas en el ámbito del espacio de fallas que tengan efectos catastróficos en el comportamiento del sistema. A continuación, se presentan algunos métodos que pueden ayudar a la inyección de fallas a explorar eficientemente el espacio de fallas para alcanzar una mayor cobertura de fallas en menos tiempo de simulación.

Herramientas de inyección de fallas

Aunque este tipo de fallos se pueden inyectar manualmente, la posibilidad de introducir un fallo no deseado es alta, por lo que existen herramientas para analizar un programa automáticamente e insertar fallos.

Herramientas de investigación

Se han desarrollado varias herramientas SWIFI y aquí se ofrece una selección de ellas. Las seis herramientas de inyección de fallos más utilizadas son Ferrari, FTAPE, Doctor, Orchestra, Xception y Grid-FIT.

Herramientas comerciales

Bibliotecas

Inyección de fallos en propiedades funcionales o casos de prueba

A diferencia de las pruebas de mutación tradicionales, en las que se generan fallas mutantes y se inyectan en la descripción del código del modelo, también se ha investigado la aplicación de una serie de operadores de mutación recientemente definidos directamente a las propiedades del modelo en lugar de al código del modelo. [29] Las propiedades mutantes que se generan a partir de las propiedades iniciales (o casos de prueba) y que son validadas por el verificador de modelos deben considerarse como propiedades nuevas que se han omitido durante el procedimiento de verificación inicial. Por lo tanto, agregar estas propiedades recientemente identificadas a la lista existente de propiedades mejora la métrica de cobertura de la verificación formal y, en consecuencia, conduce a un diseño más confiable.

Aplicación de inyección de fallas

La inyección de fallos puede adoptar muchas formas. En las pruebas de sistemas operativos , por ejemplo, la inyección de fallos suele ser realizada por un controlador ( software en modo kernel ) que intercepta llamadas del sistema (llamadas al kernel) y devuelve aleatoriamente un fallo para algunas de las llamadas. Este tipo de inyección de fallos es útil para probar software en modo usuario de bajo nivel. Para software de nivel superior, varios métodos inyectan fallos. En código administrado , es común utilizar instrumentación . Aunque la inyección de fallos se puede realizar a mano, existen varias herramientas de inyección de fallos para automatizar el proceso de inyección de fallos. [30]

Dependiendo de la complejidad de la API para el nivel en el que se inyectan las fallas, las pruebas de inyección de fallas a menudo deben diseñarse cuidadosamente para minimizar la cantidad de falsos positivos. Incluso una prueba de inyección de fallas bien diseñada a veces puede producir situaciones que son imposibles en el funcionamiento normal del software. Por ejemplo, imagine que hay dos funciones de API , Commity PrepareForCommit, de modo que, por sí solas, cada una de estas funciones puede fallar, pero si PrepareForCommitse llama y tiene éxito, se garantiza que una llamada posterior a Committendrá éxito. Ahora considere el siguiente código:

 error = PrepareForCommit (); si ( error == ÉXITO ) { error = Commit (); afirmar ( error == ÉXITO ); }

A menudo, no será posible que la implementación de inyección de errores realice un seguimiento de suficiente estado para garantizar lo que garantizan las funciones de la API. En este ejemplo, una prueba de inyección de errores del código anterior podría afectar a assert , mientras que esto nunca sucedería en una operación normal.

Véase también

Referencias

  1. ^ Moradi, Mehrdad; Van Acker, Bert; Vanherpen, Ken; Denil, Joachim (2019). "Inyección de fallas híbridas implementadas por modelos para Simulink (demostraciones de herramientas)". En Chamberlain, Roger; Taha, Walid; Törngren, Martin (eds.). Sistemas ciberfísicos. Diseño basado en modelos . Apuntes de clase en informática. Vol. 11615. Springer International Publishing. págs. 71–90. doi :10.1007/978-3-030-23703-5_4. ISBN 9783030237035.S2CID 195769468  .
  2. ^ Shepherd, Carlton; Markantonakis, Konstantinos; Van Heijningen, Nico; Aboulkassimi, Driss; Gaine, Clement; Heckmann, Thibaut; Naccache, David (2021). "Inyección de fallas físicas y ataques de canal lateral en dispositivos móviles: un análisis exhaustivo". Computadoras y seguridad . 111 (102471). Elsevier: 102471. arXiv : 2105.04454 . doi :10.1016/j.cose.2021.102471. S2CID  236957400.
  3. ^ Bar-El, Hagai; Choukri, Hamid; Naccache, David; Tunstall, Michael; Whelan, Claire (2004). "La guía del aprendiz de brujo para los ataques de falla". Actas del IEEE . 94 (2). IEEE: 370–382. doi :10.1109/JPROC.2005.862424. S2CID  2397174.
  4. ^ J. Voas, "Inyección de fallas para las masas", Computer, vol. 30, págs. 129-130, 1997.
  5. ^ ab Kaksonen, Rauli. Un método funcional para evaluar la seguridad de la implementación de protocolos. 2001.
  6. ^ A. Avizienis, J.-C. Laprie, Brian Randell y C. Landwehr, "Conceptos básicos y taxonomía de la informática confiable y segura", Dependable and Secure Computing, vol. 1, págs. 11–33, 2004.
  7. ^ ab JV Carreira, D. Costa y SJ G, "La inyección de fallas verifica la confiabilidad del sistema informático", IEEE Spectrum, págs. 50-55, 1999.
  8. ^ Benso, Alfredo; Prinetto, Paolo, eds. (2003). Técnicas y herramientas de inyección de fallas para la evaluación de la confiabilidad de sistemas integrados. Frontiers in Electronic Testing. Springer US. ISBN 978-1-4020-7589-6.
  9. ^ "Optimización de la inyección de fallas en la co-simulación FMI mediante partición de sensibilidad | Actas de la Conferencia de Simulación de Verano de 2019". dl.acm.org . Consultado el 14 de junio de 2020 .
  10. ^ Moradi, M., Oakes, BJ, Saraoglu, M., Morozov, A., Janschek, K. y Denil, J., 2020. EXPLORACIÓN DEL ESPACIO DE PARÁMETROS DE FALLA UTILIZANDO LA INYECCIÓN DE FALLA BASADA EN EL APRENDIZAJE DE REFUERZO.
  11. ^ Rickard Svenningsson, Jonny Vinter, Henrik Eriksson y Martin Torngren, "MODIFI: una herramienta de inyección de fallas implementada por MODel", Lecture Notes in Computer Science, 2010, Volumen 6351/2010, 210-222.
  12. ^ GA Kanawati, NA Kanawati y JA Abraham, "FERRARI: Un sistema flexible de inyección de errores y fallas basado en software", IEEE Transactions on Computers, vol. 44, págs. 248, 1995.
  13. ^ T. Tsai y R. Iyer, "FTAPE: una herramienta de inyección de fallas para medir la tolerancia a fallas", presentado en Computing in aerospace, San Antonio; TX, 1995.
  14. ^ S. Han, KG Shin y HA Rosenberg, "DOCTOR: Un entorno integrado de inyección de fallas de software para sistemas distribuidos en tiempo real", presentado en el Simposio internacional sobre rendimiento y confiabilidad de computadoras, Erlangen, Alemania, 1995.
  15. ^ S. Dawson, F. Jahanian y T. Mitton, "ORCHESTRA: Un entorno de sondeo e inyección de fallos para probar implementaciones de protocolos", presentado en el Simposio internacional sobre rendimiento y confiabilidad de computadoras, Urbana-Champaign, EE. UU., 1996.
  16. ^ Sitio web de Grid-FIT Archivado el 2 de febrero de 2008 en Wayback Machine.
  17. ^ N. Looker, B. Gwynne, J. Xu y M. Munro, "Un enfoque basado en ontología para determinar la confiabilidad de arquitecturas orientadas a servicios", en las actas del 10º Taller internacional IEEE sobre sistemas confiables en tiempo real orientados a objetos, EE. UU., 2005.
  18. ^ N. Looker, M. Munro y J. Xu, "Una comparación de la inyección de fallas a nivel de red con la inserción de código", en las actas de la 29.ª Conferencia internacional sobre software y aplicaciones informáticas del IEEE, Escocia, 2005.
  19. ^ Sitio web de LFI
  20. ^ Flatag (16 de mayo de 2020), Flatag/FIBlock , consultado el 16 de mayo de 2020
  21. ^ Información del producto beSTORM
  22. ^ Sitio de herramientas SWIFI de ExhaustiF
  23. ^ Descripción general del producto Holodeck Archivado el 13 de octubre de 2008 en Wayback Machine
  24. ^ Descripción general del producto Codenomicon Defensics
  25. ^ Analizador de servicios Mu
  26. ^ Mu Dinámicas, Inc.
  27. ^ Sitio web de Xception
  28. ^ Software crítico SA
  29. ^ Abbasinasab, Ali; Mohammadi, Mehdi; Mohammadi, Siamak; Yanushkevich, Svetlana; Smith, Michael (2011). "Inyección de fallas mutantes en propiedades funcionales de un modelo para mejorar las métricas de cobertura". 2011 14.ª Conferencia Euromicro sobre diseño de sistemas digitales . págs. 422–425. doi :10.1109/DSD.2011.57. ISBN. 978-1-4577-1048-3.S2CID15992130  .​
  30. ^ N. Looker, M. Munro y J. Xu, "Simulación de errores en servicios web", Revista internacional de sistemas de simulación, ciencia y tecnología, vol. 5, 2004.

Enlaces externos