Qui a tué le switch réseau ? L’histoire du bug « Hubris »

L’histoire du bug Hubris : qui a tué le switch réseau ?

• Qu’est-ce que Hubris ?

  • Hubris est un système d’exploitation pour les systèmes profondément embarqués, conçu pour des ordinateurs qui ne sont pas reconnus comme tels, comme l’intérieur d’un clavier.
  • Il a été développé pour gérer tout ce qui est nécessaire au démarrage des gros processeurs dans l’Oxide Rack.
  • Hubris est assez unique, et les aspects pertinents pour cette histoire sont décrits ci-dessous.

• La scène du crime

  • Un collègue d’Oxide, Arjen Roodselaar, responsable du firmware du switch réseau, testait des modifications de la séquence d’alimentation et de la configuration de l’horloge.
  • Après un petit changement, le switch a soudainement cessé de démarrer.
  • Une partie du firmware répondait encore, mais la partie critique chargée de la séquence d’alimentation était arrêtée.

• Tirer davantage d’un RAM limité

  • Les microcontrôleurs bon marché qui utilisent Hubris disposent de très peu de RAM et de flash.
  • Hubris se compose de nombreux programmes compilés séparément, appelés tâches, ce qui lui donne des besoins en ressources légèrement plus élevés que d’autres systèmes d’exploitation.
  • Un collègue, Matt Keeter, a récemment rendu le système plus intelligent afin d’essayer de regrouper les tâches aussi efficacement que possible à l’aide de plusieurs régions de taille puissance de deux.

• L’arme du crime

  • Arjen a utilisé Humility, le débogueur de Hubris, pour examiner le switch réseau en panne.
  • Avec la commande humility tasks, il a affiché la liste des tâches en cours d’exécution sur le processeur ainsi que leurs informations d’état.
  • Il a découvert que la tâche chargée de la séquence d’alimentation avait redémarré 115 fois à cause d’une faute mémoire.

• Étendre les emprunts Rust entre tâches dans l’IPC de Hubris

  • Les tâches Hubris peuvent s’envoyer des messages entre elles via l’IPC.
  • Les messages ressemblent beaucoup à des appels de fonction et se comportent de manière très similaire.
  • Lorsqu’une tâche prête de la mémoire à une autre, elle ne doit évidemment pas essayer de prêter de la mémoire qu’elle ne possède pas réellement.

• Quand une fonctionnalité devient une attaque

  • Deux fonctionnalités peuvent se combiner pour créer un bug.
  • Le regroupement des tâches fonctionne de manière opportuniste dans le système de build.
  • Si la taille de la tâche A change légèrement, la position des limites de région MPU d’une tâche B sans rapport peut se déplacer.

• L’appel vient de l’intérieur !

  • Il a fallu modifier l’algorithme de protection mémoire.
  • Il fallait autoriser la mémoire prêtée à traverser les limites des régions MPU.

• Échouer avec Hubris

  • Plusieurs choses ne se sont pas produites lorsque le système a échoué.
  • Le switch réseau en panne a pu être réparé en trois heures.
  • L’isolement des pannes, l’échec sûr, la mémoire partagée sûre, la co-conception noyau-débogueur, la simplicité de la conception et de l’implémentation, ainsi que l’intégration étroite et non hiérarchique de l’équipe ont tous été utiles.

L’avis de GN⁺

• Cet article montre, à travers le processus d’identification et de résolution d’un bug dans le système d’exploitation Hubris, l’importance d’une conception logicielle robuste même dans des systèmes complexes.
• Le processus de découverte et de correction du bug souligne l’importance du travail d’équipe et d’outils de débogage efficaces pour résoudre des problèmes complexes d’ingénierie logicielle.
• Il montre aussi à quel point les fonctions d’isolation du système et de gestion des défaillances sont importantes lorsqu’on utilise un système comme Hubris. Elles peuvent considérablement améliorer la stabilité et la maintenabilité du système.
• Cet article montre également comment l’utilisation d’un langage de programmation sûr comme Rust permet de garantir la sûreté mémoire et de minimiser les bugs. Dans les systèmes qui utilisent Rust, ce type de bug est rare, ce qui prouve concrètement l’efficacité des garanties de sûreté mémoire de Rust.
• Parmi les projets ou produits comparables offrant des fonctionnalités similaires, on peut citer seL4, FreeRTOS et Zephyr, qui sont chacun des systèmes d’exploitation embarqués avec des objectifs et des caractéristiques différents.
• Lors de l’adoption d’un système comme Hubris, il faut prendre en compte des éléments tels que les contraintes mémoire, la gestion des tâches et la conception du mécanisme IPC. Les avantages d’un tel choix résident dans une conception système robuste et une gestion sûre de la mémoire, tandis que ses inconvénients peuvent être la complexité du système et la courbe d’apprentissage.

[GN⁺]

Avis sur Hacker News

• Revue du code du noyau Hubris

  • J’ai lu le code du noyau de Hubris pendant une demi-heure, et il est très clair et bien écrit. C’est très différent du code C complexe avec macros, noms de variables à deux lettres et peu de commentaires que j’avais vu auparavant. Je le recommande comme lecture avant de dormir.

• Éloges pour l’offre d’emploi

  • C’est l’une des meilleures offres d’emploi que j’aie jamais vues. La transition vers la culture d’entreprise est naturelle et se termine par « nous recrutons ». C’est même un excellent post-mortem compréhensible par des développeurs au niveau applicatif. J’étais prêt pour ce genre de contenu, car j’étudie actuellement Rust. Et c’est toujours un plaisir de voir le travail de quelqu’un d’autre quand il a mis beaucoup de commentaires dans le code.

• Revue de code et suggestion

  • Une petite remarque sur le code : comme il ne s’agit pas d’un détail d’une fonction particulière, mais d’un commentaire sur un invariant d’un champ qui doit être respecté par tous les auteurs et utilisé par tous les lecteurs, il vaudrait mieux l’ajouter à la chaîne de documentation de TaskDesc::regions.

• Évaluation du processus de débogage

  • Cela offre une analyse approfondie du débogage d’un problème complexe, et le fait que le reste du système soit resté stable témoigne du travail d’ingénierie de grande qualité de l’équipe d’Oxide. Personnellement, cela m’inspire à appliquer des techniques similaires au travail.

• Intérêt pour la culture de l’équipe Oxide

  • L’équipe d’ingénierie d’Oxide n’est pas isolée en interne et a une culture qui encourage l’ouverture, la curiosité et la communication, tout en décourageant l’attitude défensive, la construction d’empires et le gatekeeping. Ils ont fait des efforts pour créer et préserver cette culture, et cela se voit dans leur manière de s’organiser horizontalement à travers ce que d’autres organisations appelleraient des équipes distinctes. J’aimerais en savoir plus sur les motivations et les détails concrets de mise en œuvre pour créer une telle culture. Je me demande s’il y a des inconvénients à encourager « l’ouverture, la curiosité et la communication » au sein d’une organisation, s’il y a des cas où l’on choisirait un système hiérarchique plus strict, et j’ai l’impression que l’organigramme devrait être une décision stratégique, mais j’en comprends mal les compromis.

• Lien vers des informations associées

  • Des informations préalables peuvent être trouvées via le lien fourni.

• Empathie face aux problèmes rencontrés lors du débogage

  • Je compatis : les plantages aléatoires qui disparaissent dès qu’on ajoute du code de débogage sont les pires.

• Suggestion sur le traitement matériel

  • Il est mentionné qu’on pourrait prendre en charge plus de huit régions en traitant le matériel comme un TLB software-filled.

• Éloges pour le travail d’Oxide

  • Étonnement devant le travail accompli par Oxide.

• Réaction au nom du système d’exploitation

  • Surprise et réaction au fait d’avoir nommé le système d’exploitation Hubris.