Tutorial SASE2011

µAgenda Introducción: testing e inyección de defectos Introducción: Protocolo USB Inyección de defectos sobre USB
Inyección de defectos y su aplicación en

dispositivos USB
Ariel Sabiguero Andrés Aguirre
Instituto de Computación
Facultad de Ingenierı́a
Universidad de la República, Uruguay
{asabigue|aaguirre}@fing.edu.uy
3/3/2011
A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

1 Introducción: testing e inyección de defectos

¿qué es probar?
Conceptos...
La visión del servicio
2 Introducción: Protocolo USB
Conceptos generales
Tipos de endpoints
Un poco más de detalle
Uso de USB en los sistemas embebidos
3 Inyección de defectos sobre USB
Conceptos generales
¿Porqué inyección de defectos sobre USB?
Conceptos básicos de USB en GNU/Linux
Herramienta para inyectar defectos en USB

¿qué es probar?
Testing
Glenford Myers
Testear (probar) es el proceso de ejecutar un programa con el obje-
tivo de encontrarle errores.
IEEE
Una actividad en la cual un sistema o componente es ejecutado bajo
condiciones especificadas, sus resultados son observados o grabados
y una evaluación es hecha de algún aspecto del sistema o compo-
nente.

¿qué es probar?
Verificación y testing

¿qué es probar?
... no olvidemos que
Edsger Dijkstra
El testing puede ser usado para mostrar la presencia de bugs, pero
nunca para mostrar su ausencia!

¿qué es probar?
Hay que probar más
Aeroespacio: Mariners 1, 3, 8, Ariane 5 (1996)

Sobredosis radiológicas en Panamá
Durante 2006, el 60% de los automóviles de una marca de
lujo alemana volvieron a taller por fallas en el software
Las menos notorias, están entre nosotros
¿colgadas de nuestros PCs?
¿colgadas de celulares?
¿el cambiador de CDs?

¿qué es probar?
Costo y dificultades
Del 50% al 60% del costo total (recursos humanos y

materiales) en el ciclo de vida completo van a testing
Dificultades
vinculadas a la comprensión del proceso de introducción de
errores en el sistema final
de orden psicológico y/o cultural
formales: no puede existir un algoritmo o máquina capaz de
demostrar la exactitud total de ningún sistema

Conceptos...
defecto (fault)
Es una anomalı́a en el software, en el hardware o en los datos que
tienen el potencial de causar errores y fallos. Ejemplos de defectos
incluyen cortos en circuitos de hardware, o la división por cero en
un fallo de software. Los defectos son las causas de los errores, pero
no todo defecto lleva a un error. Un defecto se dice activo cuando
produce un error.

Conceptos...
error (error)
Es la ocurrencia de la condición inválida o valor incorrecto en el
sistema. La interacción entre el defecto y un estı́mulo es lo que
produce el error. Un error es entonces la manifestación de un defecto
en el sistema. Un error es por naturaleza temporal. Existen dos
estados posibles de un error: latente y detectado. Un error es latente
mientras no ha sido reconocido como tal. Puede ser detectado por
mecanismos de detección o por los efectos del error sobre el sistema.
falla (failure)
de un sistema se da cuando el mismo no se comporta de acuerdo a
su especificación.

Conceptos...
Relación entre Defecto, Error y Falla

Conceptos...
Clasificación de defectos

Conceptos...
Defectos por duración
Defectos permanentes: son irreversibles. La recuperación de

estos defectos se logra solo con el reemplazo del componente
dañado.
Defectos transitorios: son usualmente causados por
elementos del entorno que interactúan con el sistema,
causando que el mismo entre en un estado erróneo.
Defectos intermitentes: Ocurren debido a hardware
inestable o variaciones en el estado del hardware.

Definiendo dependability:
En los últimos años se ha avanzado en la formalización de

parámetros y caracterı́sticas de los sistemas que van más allá de su
definición funcional clásica (conformance e interoperability).
La provisión de servicios por aplicaciones de infraestructura

depende fuertemente de la correcta operación de sistemas de
información, y la falla de estos generalmente elimina servicios de
infraestructura rápida y completamente.

Definiendo dependability:(cont)
La dependability es una propiedad que un sistema puede tener y

usualmente es definida como un conjunto de requerimientos que un
sistema debe cumplir.
Veremos dependability en función de otras propiedades o aspectos

como reliability, availability, safety y survivability entre otros.

Definiciones
Reliability
R(t) es la probabilidad que un sistema cumpla sus requerimientos
hasta un tiempo t cuando opera bajo sus condiciones establecidas
de funcionamiento.
Availability
A(t) es la probabilidad que un sistema esté operando correctamente
en el instante de tiempo t.

Definiciones (cont)
Safety
S(t) es la probabilidad que condiciones que pueden derivar en una
situación adversa, no ocurran, independientemente de si el sistema
cumple o no con su misión. Especialmente se deben considerar daños
a la propiedad, medio ambiente e incluso, vidas humanas.

a modo de ejemplo...
A los sistemas de control embebidos usualmente se les

requiere altos niveles de reliability (confiabilidad).
A los sistemas de base de datos en producción generalmente
se les requieren altos niveles de availability (disponibilidad).
A los sistemas de control de tránsito se les requieren altos
niveles de safety (seguridad).

Observaciones
Hay quienes sostienen que safety no es una propiedad que describa

el software, dado que éste nunca puede causar un daño directamente
(no es hardware).

Observaciones
Es interesante notar que los aspectos anteriores pueden ser

independientes, y un nivel alto en uno puede no involucrar a otro.
A modo de ejemplo, pensemos en un sistema que falla

frecuentemente, pero que su restauración es casi inmediata,
teniendo tiempos de indisponibilidad (unavailability ) casi
imperceptibles. Este ejemplo tiene alta disponibilidad y baja
confiabilidad.

Observaciones (cont)
Muchos sistemas son ası́ diseñados -alta disponibilidad sin

demasiado cuidado por la confiabilidad- por razones de costos
cuando la confiabilidad (desde el punto de vista de su definición
formal) no es requerida.
En general, los requerimientos de confiabilidad buscan desarrollar

un sistema libre de fallos, mientras que los requerimientos de
(safety ) buscan sistemas que no produzcan incidentes.
No todos los errores en el software causan problemas del tipo de
safety, y no todo el software que funciona de acuerdo con su
especificación es seguro.

Definiciones (cont)
Survivability
Informalmente, cuando decimos que un sistema es survivable esta-
mos diciendo que posee la capacidad de continuar brindando ser-
vicios (posiblemente degradados o diferentes) en un entorno dado,
cuando diversos eventos causan un daño mayor al sistema o su en-
torno operativo.
Un sistema es survivable si cumple con su especificación de surviv-
ability.

Observaciones
Cuando hacemos que un sistema sea survivable, nos referimos a la

misión del sistema, más que los componentes del mismo. En
otras palabras, diseñamos un conjunto de componentes que brindan
un servicio que se brinda incluso ante el caso de degradación.
Este es otro aspecto que hace a la dependability de un sistema.

No hay presuposiciones de cómo se debe alcanzar: es un aspecto
de diseño del sistema.

Definiciones (cont)
Survivability specification
de un sistema es:
a)Una declaración precisa del entorno operativo esperado del
sistema
b)Un conjunto de especificaciones que definen las funciones
que un sistema debe proveer
c)Un orden del conjunto de funciones denotado como el orden
preferido de provisión de las funciones
d)Una distribución de probabilidad sobre el conjunto de
especificaciones. La probabilidad asociada a una
especificación dada es la probabilidad que la especificación
asociada sea cumplida.

Intuitivamente
Por a), un sistema que cumple con su especificación de

survivability será capaz de proveer la funcionalidad preferida con
cierta probabilidad.
Por b) establecemos que si por alguna razón no es posible, el
sistema brindará el siguiente nivel preferido de servicio.
En c) definimos el orden preferido de servicios, que reflejará la
importancia dada organizacionalmente a los mismos.

Inyección de defectos
inyección de defectos
Se define como un mecanismo de validación de dependability de un
sistema, en base a la realización de experimentos controlados, en los
que explı́citamente se introducen defectos al mismo.
HWIFI - Hardware Implemented Fault Injection

SWIFI - Software Implemented Fault Injection


Conceptos generales
Caracterı́sticas de la tecnologı́a USB
Bus de comunicación serial

Varias velocidades
Low speed – 1.5 Mbit/sec desde USB 1.0
Full speed – 12 Mbit/sec desde USB 1.1
High speed – 480 Mbit/sec desde USB 2.0
Super speed – 3.2 Gbit/sec desde USB 3.0
Detección y configuración automática de los periféricos.
El bus es arbitrado por el Host, los dispositivos juegan el rol
de esclavos
USB OTG
Wireless USB

Conceptos generales
Como se comunican los dispositivos
Configuraciones
Interfaces
Representan diferentes funcionalidades

Conceptos generales
Endpoints
Todo el tráfico en el bus viaja desde o hacia un device

endpoint
Tı́picamente un endpoint es un bloque de memoria de datos o
un registro en el chip del controlador
Poseen dirección (0 a 15) y sentido (IN, OUT)
Tipos:
Control
Bulk
Interrupt
Isochronous

Tipos de endpoints
Control Endpoints
Usados para configurar el dispositivo, obtener información,

enviar comandos, obtener información de estado
Todo dispositivo tiene un endpoint de control (endpoint 0),
utilizado para configurarlo al momento de ser conectado
Utilizado para transferir pequeñas cantidades de datos
El protocolo garantiza que la que siempra exista un porcentaje
del ancho de banda reservada para estas transferencias (10%)

Tipos de endpoints
Bulk Endpoints
Transferencias esporádicas utilizando el ancho de banda

remanente del bus
Utilizadas para transferir cantidades grandes de datos
No hay garatı́as respecto al ancho de banda
Reintentos automáticos
Utilizado tı́picamente en unidades de almacenamiento,
impresoras, interfaces de red

Tipos de endpoints
Interrupt Endpoints
Transferencias periódicas
Utilizadas para transferir cantidades pequeñas de datos
Ancho de banda garantizado
Reintentos automáticos
Utilizada en dispositivos que requieren tiempos de respuesta
garantidos (mouse, teclados)
El host interroga (pooling ) al dispositivo
No interrumpe

Tipos de endpoints
Isochronous Endpoints
Transferencias periódicas
Utilizadas para transferir cantidades grandes de datos
Tienen velocidad garantizada en el bus
No tiene reintentos automaticos
Utilizado para transferencias con caracterı́sticas de tiempo real
(audio y video)

Clases de dispositivos
Cuando un grupo de dispositivos o interfaces comparten

muchos atributos, proveen o requieren de servicios similares,
tiene sentido definir los atributos y servicios en una
especificación de clase
Los sistemas operativos pueden proveer drivers para las clases
en común, eliminando la necesidad de que los vendedores de
dispositivos tengan que proveerlos para los dispositivos en esas
clases
Ejemplos: Audio, HID, Printer, Smart Card, Video, ...,
Custom

El proceso de enumeración
El host necesita aprender de los dispositivos

Es un proceso de intercambio de información por el cual el
host descubre que tipo de dispositivo es y requerimientos de
consumo y otras caracterı́sticas.
Una vez finalizado, el sistema operativo le asigna un driver y
el dispositivo esta listo para transferir datos.

El proceso de enumeración

Motivación
Tradicionalmente los dispositivos USB eran utilizados

principalmente en sistemas de proposito general
En sistemas embebidos generalmente se utilizan módulos
perfiféricos con protocolos de comunicación del tipo I2C, SPI,
serial, paralelo
Desde un tiempo a esta parte ha aumentado la presencia de
Host Controllers en hardware utilizado en sistemas embebidos
(System on a Chip)

Ventajas
Existen estándares definidos (clases en la jerarquı́a de

dispostivos USB)
Brindan independencia del fabricante
Sistemas operativos ya implementan device drivers para las
clases de la jerarquia USB (WiFi, Bluetooth, video, audio)
Menor Costo

Ventajas vs Complejidad
Estas ventajas al usuario redundan en una mayor complejidad

de la tecnologı́a comparada con otras sin estas caracterı́sticas
(rs232, paralelo)
Mayor dificultad para asegurar que la implementación del
dispositivo o host USB se comporta correctamente de acuerdo
a su especificación
Permite trabajar con un nivel de abstracción alto, pero se debe
estar conciente de los problemas que pueden llegar a ocurrir
para lograr diseñar sistemas embebidos de buena calidad.


El hardware también falla
Aún bajo implementaciones “perfectas” del firmware, drivers

del dispositivo, sistema operativo, este va a estar inmerso en
un ambiente externo el cual puede afectar el correcto
funcionamiento
Defectos transitorios
Interferencia electromágnetica (EMI)
Rayos cósmicos
Cables defectuosos, de baja calidad o poco robustos

Impactos de los defectos transitorios en tecnologı́a USB
Entre otros producen errores en la consistencia de la

información transmitida entre el host y el device
Problemas en el proceso de enumeración
Reintentos pueden afectar la experiencia del usuario
Afectan directamente la reliability, availability y safety (RAS)
del sistema

Diseñando de manera defensiva
Algunos device drivers son implementados teniendo en mente

estos problemas
De todas formas al momento de diseñar un sistema embebido
se debe ser consciente de estos problemas
En muchos casos no puedo aumentar la reliability
Si puedo buscar alternativas para aumentar la availability del
sistema:
Reintentar transmisión
Reconfigurar dispositivo (re-enumerar)
Reiniciar dispostivo/sistema

Ejemplos de soft errors en producción
08:17:00 kernel: [150021.366375] hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
08:17:00 kernel: [150021.373151] usb 3-2: USB disconnect, address 19
08:17:00 kernel: [150021.676056] usb 3-2: new full speed USB device using ohci hcd and address 20
08:17:00 kernel: [150021.900474] usb 3-2: configuration #1 chosen from 1 choice
08:17:01 kernel: [150022.244063] usb 3-2: reset full speed USB device using ohci hcd and address 20
08:17:01 kernel: [150022.450354] usb 3-2: can’t restore configuration #1 (error=-62)
08:17:01 kernel: [150022.457089] usb 3-2: USB disconnect, address 20
08:17:01 kernel: [150022.760048] usb 3-2: new full speed USB device using ohci hcd and address 21
08:17:01 kernel: [150022.984470] usb 3-2: configuration #1 chosen from 1 choice
08:17:02 kernel: [150024.099349] usb 3-2: device descriptor read/all, error -62
1m 1h
150000s · 60s · 60m ≥ 41hs desde el inicio del sistema

Aumentando la calidad del sistema
Los problemas producidos por defectos transitorios pueden

llevar a fallos que ocurren esporádicamente y donde las
situaciones que lo provocan son difı́ciles de reproducir
La inyección de defectos es un técnica útil para lograr
reproducir situaciones que ocurren de forma exporádica y
permite probar que el sistema bajo prueba las resuelve

URB’s
Los datos intercambiados entre el sistema y los dispositivos se

hace en unidades llamadas URB (USB Request Block)
Son similares a los paquetes de Internet (red IP)
Cada endpoint puede manejar una cola de URBs
Posee un campo status donde se puede consultar si ocurrieron
errores en la comunicación

Errores tı́picos debido al cable USB o al firmware del

dispositivo
El campo status toma los valores:

-EPROTO: Bitstuff error, no se recibió paquete de respuesta en
tiempo por el hardware, o error USB desconocido
-EILSEQ: error de CRC, no se recibió paquete de respuesta en
tiempo por el hardware, o error USB desconocido
-EOVERFLOW: La cantidad de datos retornados por el endpoint
fue mayor que el mayor tamaño de paquete del endpoint o el
espacio disponible en el buffer

Otros tipos interesantes de error
El campo status toma los valores:

-EINPROGRESS: siendo porcesado por el host controller
-ECOMM: Los datos se recibieron más rápido de lo que pueden
escribirse
-ENOSR: no puede proveerse la información desde la memoria
del sistema a la velocidad necesaria para cumplir con la tasa
requerida.
-ESHUTDOWN: error severo con el USB host controller driver
está deshabilitado o el dispositivo fue desconectado.
.... hay muchos valores más

Prototipo construido
Permite inyectar defectos sobre el protocolo USB

Intenta brindar una herramienta que permita ejecutar
situaciones de error de forma repetible
Principalmente centrado en inyectar defectos similares a los
producidos por defectos transitorios
Permite evaluar como responden los device drivers ante
defectos hardware
Parte de la tesis de grado de Juan Gómez y Álvaro Martı́nez

Demo

Ejemplo de inyección
Determinar el dispositivo al que queremos inyectar

lsusb
Cargamos el módulo del kernel que hace la inyección

insmod usbfi.ko
Cargamos el intérprete de comandos

./fik x86 1
Indicamos el dispositivo al que queremos hacer la inyección

usbdevice 04fc 0013
Definimos la inyección
usbstatus 1 5 1 -84
Conclusiones
Las tendencias en dispositivos embebidos indican que se

incrementará el reuso de componentes de alto nivel (placas,
sistemas operativos y subcomponentes complejos)
La complejidad de los desarrollos obligan al uso de técnicas
avanzadas para la detección y corrección de errores
Más allá de las técnicas utilizadas para el testing funcional, los
requerimientos de dependability obligan a pruebas en
condiciones adversas, pero a la vez repetibles y económicas
La inyección de defectos por software es una herramienta muy
adecuada para abordar los proyectos de desarrollo embebidos
actuales

Muchas gracias por su tiempo
¿preguntas?

Inyección de defectos y su aplicación en

dispositivos USB
Ariel Sabiguero Andrés Aguirre
Instituto de Computación
Facultad de Ingenierı́a
Universidad de la República, Uruguay
{asabigue|aaguirre}@fing.edu.uy
3/3/2011

Tutorial SASE2011

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tutorial SASE2011

Cargado por

Copyright:

Formatos disponibles

µAgenda Introducción: testing e inyección de defectos Introducción: Protocolo USB Inyección de defectos sobre USB

Inyección de defectos y su aplicación en

Ariel Sabiguero Andrés Aguirre

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

1 Introducción: testing e inyección de defectos

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

... no olvidemos que

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

Hay que probar más

Aeroespacio: Mariners 1, 3, 8, Ariane 5 (1996)

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

Del 50% al 60% del costo total (recursos humanos y

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

Relación entre Defecto, Error y Falla

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

Defectos por duración

Defectos permanentes: son irreversibles. La recuperación de

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

En los últimos años se ha avanzado en la formalización de

La provisión de servicios por aplicaciones de infraestructura

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

La dependability es una propiedad que un sistema puede tener y

Veremos dependability en función de otras propiedades o aspectos

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

A los sistemas de control embebidos usualmente se les

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

Hay quienes sostienen que safety no es una propiedad que describa

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

Es interesante notar que los aspectos anteriores pueden ser

A modo de ejemplo, pensemos en un sistema que falla

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

Muchos sistemas son ası́ diseñados -alta disponibilidad sin

En general, los requerimientos de confiabilidad buscan desarrollar

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

Cuando hacemos que un sistema sea survivable, nos referimos a la

Este es otro aspecto que hace a la dependability de un sistema.

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

Por a), un sistema que cumple con su especificación de

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB

La visión del servicio

HWIFI - Hardware Implemented Fault Injection

A. Sabiguero, A. Aguirre (InCo-FING-UdelaR) Inyección y USB