¿Quién mató al switch de red? La historia del “bug de Hubris”

La historia del bug de Hubris: ¿quién mató al switch de red?

• ¿Qué es Hubris?

  • Hubris es un sistema operativo para sistemas profundamente embebidos, diseñado para computadoras que no se perciben como computadoras, como el interior de un teclado.
  • Fue desarrollado para encargarse de todo lo necesario para arrancar los procesadores grandes en el Oxide Rack.
  • Hubris es bastante singular, y la parte relevante para esta historia se explica más abajo.

• La escena del crimen

  • El colega de Oxide, Arjen Roodselaar, responsable del firmware del switch de red, estaba probando cambios en la secuencia de energía y la configuración del reloj.
  • Después de un cambio pequeño, de pronto el switch dejó de encender.
  • Parte del firmware seguía respondiendo, pero la parte crucial encargada de la secuencia de alimentación se había detenido.

• Sacarle más provecho a una RAM limitada

  • Los microcontroladores económicos que usan Hubris tienen RAM y flash muy limitadas.
  • Hubris está compuesto por muchos programas compilados por separado llamados tareas, por lo que tiene requisitos de recursos un poco más altos que otros sistemas operativos.
  • El colega Matt Keeter había hecho recientemente que el sistema fuera más inteligente para intentar empaquetar las tareas lo mejor posible usando varias regiones de potencia de dos.

• La pistola humeante

  • Arjen investigó el switch de red averiado usando Humility, un depurador para Hubris.
  • Usó el comando humility tasks para imprimir la lista de tareas en ejecución en el procesador y su información de estado.
  • Descubrió que la tarea encargada de la secuencia de alimentación se había reiniciado 115 veces debido a una falla de memoria.

• Extender los préstamos de Rust entre tareas en el IPC de Hubris

  • Las tareas de Hubris pueden enviarse mensajes entre sí mediante IPC.
  • Los mensajes se ven y se comportan de forma muy similar a las llamadas a función.
  • Cuando una tarea presta memoria a otra, no debería intentar prestar memoria que en realidad no posee.

• Cuando las funciones atacan

  • Dos funciones pueden combinarse y convertirse en un bug.
  • El empaquetado de tareas funciona de manera oportunista en el sistema de compilación.
  • Si el tamaño de la tarea A cambia ligeramente, la posición de los límites de región del MPU de la tarea B, sin relación con ella, puede desplazarse.

• ¡Llaman desde dentro!

  • Había que cambiar el algoritmo de protección de memoria.
  • Debía permitirse que la memoria prestada cruzara regiones del MPU.

• Fallar con Hubris

  • Hubo varias cosas que no ocurrieron cuando el sistema falló.
  • El switch de red averiado pudo repararse en tres horas.
  • Ayudaron el aislamiento de fallas, fallar de forma segura, la memoria compartida segura, el codiseño entre kernel y depurador, la simplicidad del diseño y la implementación, y la integración cercana y no jerárquica del equipo.

La opinión de GN⁺

• Este artículo muestra, a través del proceso de encontrar y resolver un bug ocurrido en el sistema operativo Hubris, la importancia de un diseño de software robusto incluso en sistemas complejos.
• El proceso de descubrimiento y resolución del bug destaca la importancia del trabajo en equipo y de herramientas de depuración eficientes para resolver problemas complejos de ingeniería de software.
• Muestra qué tan importantes son las funciones de aislamiento del sistema y manejo de fallas al usar un sistema como Hubris. Esto puede mejorar enormemente la estabilidad y la mantenibilidad del sistema.
• El artículo también muestra cómo usar Rust, un lenguaje de programación seguro, para garantizar la seguridad de memoria y minimizar bugs. En sistemas que usan Rust, este tipo de bug ocurre rara vez, lo que demuestra en la práctica cuán efectivas son las garantías de seguridad de memoria de Rust.
• Otros proyectos o productos con funciones similares incluyen seL4, FreeRTOS y Zephyr, que son sistemas operativos para sistemas embebidos con distintos objetivos y características.
• Al adoptar un sistema como Hubris, conviene considerar factores como las restricciones de memoria, la gestión de tareas y el diseño del mecanismo de IPC. Entre las ventajas de elegir un sistema así están un diseño robusto y una gestión segura de memoria; entre las desventajas, la complejidad del sistema y su curva de aprendizaje.

[GN⁺]

Comentarios de Hacker News

• Revisión del código del kernel de Hubris

  • Leí el código del kernel de Hubris durante media hora y está escrito con mucha claridad y muy bien. Es claramente distinto del código en C que he visto antes, lleno de macros complejas, nombres de variables de dos letras y pocos comentarios. Lo recomiendo como una buena lectura antes de dormir.

• Elogio al anuncio de trabajo

  • Este es uno de los mejores anuncios de trabajo que he visto. Hace una transición natural hacia la cultura y termina con un “estamos contratando”. Incluso es un excelente análisis post-mortem que también puede entender un desarrollador a nivel de aplicación. Actualmente estoy estudiando Rust, así que ya venía preparado para este tipo de contenido. Además, siempre es un gusto ver el trabajo de otra persona cuando ha puesto muchos comentarios en el código.

• Revisión de código y sugerencia

  • Un comentario rápido sobre el código: como esto no trata de los detalles de una función específica, sino de un comentario sobre la invariante de un campo que todos los autores deben respetar y todos los lectores pueden aprovechar, sería bueno agregarlo a la cadena de documentación de TaskDesc::regions.

• Evaluación del proceso de depuración

  • Ofrece un análisis profundo de cómo depurar un problema complejo, y que el resto del sistema se haya mantenido estable es prueba del trabajo de ingeniería de alta calidad del equipo de Oxide. Personalmente, me inspiró para aplicar técnicas parecidas en mi trabajo.

• Interés por la cultura del equipo de Oxide

  • El equipo de ingeniería de Oxide no está aislado internamente, sino que tiene una cultura que fomenta la apertura, la curiosidad y la comunicación, y desalienta las actitudes defensivas, la construcción de feudos y el gatekeeping. Han trabajado para crear y mantener esa cultura, y eso se nota en la forma en que están organizados horizontalmente a través de lo que otras organizaciones llamarían equipos. Me gustaría saber más sobre la motivación para crear esa cultura y los detalles concretos de cómo la implementan. Me pregunto si hay desventajas en promover la “apertura, curiosidad y comunicación” dentro de una organización, o si hay casos en los que conviene elegir un sistema jerárquico más estricto. Me da la impresión de que el organigrama debe decidirse estratégicamente, pero no tengo claro cuáles son los trade-offs.

• Enlace con información relacionada

  • La información previa puede encontrarse en el enlace proporcionado.

• Empatía con los problemas que surgen al depurar

  • Totalmente de acuerdo en que los fallos aleatorios que desaparecen cuando agregas código de depuración son los peores.

• Sugerencia sobre el manejo del hardware

  • Se menciona que sería posible soportar más de 8 regiones si el hardware se tratara como un TLB de llenado por software.

• Elogio al trabajo de Oxide

  • Expresa admiración por el trabajo que realiza Oxide.

• Reacción al nombre del sistema operativo

  • Muestra sorpresa y reacción por haber llamado Hubris al sistema operativo.