Quem matou o switch de rede? A história do bug "Hubris"

A história do bug Hubris: quem matou o switch de rede?

• O que é Hubris?

  • Hubris é um sistema operacional para sistemas profundamente embarcados, projetado para computadores que não são reconhecidos como computadores, como o interior de um teclado.
  • Foi desenvolvido para cuidar de todo o trabalho necessário para iniciar os processadores maiores no Oxide Rack.
  • Hubris é bastante incomum, e as partes relevantes para esta história são explicadas abaixo.

• A cena do crime

  • O colega Arjen Roodselaar, responsável pelo firmware do switch de rede da Oxide, estava testando mudanças na sequência de energia e na configuração de clock.
  • Depois de uma pequena alteração, de repente o switch deixou de ligar.
  • Parte do firmware respondia, mas a parte crítica responsável pela sequência de alimentação estava parada.

• Extraindo mais de uma RAM limitada

  • Os microcontroladores baratos que usam Hubris têm RAM e flash extremamente limitadas.
  • O Hubris é composto por muitos programas compilados separadamente, chamados de tarefas, por isso tem exigências de recursos um pouco maiores do que outros sistemas operacionais.
  • O colega Matt Keeter havia recentemente tornado o sistema mais inteligente para tentar empacotar as tarefas da melhor forma possível usando várias regiões em potências de 2.

• A arma fumegante

  • Arjen investigou o switch de rede com falha usando o Humility, o depurador do Hubris.
  • Usou o comando humility tasks para imprimir a lista de tarefas em execução no processador e as informações de estado.
  • Descobriu que a tarefa responsável pela sequência de alimentação havia reiniciado 115 vezes por causa de uma falha de memória.

• Estendendo empréstimos do Rust entre tarefas no IPC do Hubris

  • As tarefas do Hubris podem trocar mensagens entre si por meio de IPC.
  • As mensagens se parecem e funcionam de forma muito semelhante a chamadas de função.
  • Quando uma tarefa empresta memória para outra, ela não deve tentar emprestar memória que na verdade não possui.

• Quando recursos atacam

  • Duas funcionalidades podem se combinar e virar um bug.
  • O empacotamento de tarefas funciona de forma oportunista no sistema de build.
  • Se o tamanho da tarefa A mudar um pouco, a posição dos limites das regiões de MPU de uma tarefa B não relacionada pode se deslocar.

• A ligação vem de dentro!

  • O algoritmo de proteção de memória precisava ser alterado.
  • Era necessário permitir que a memória emprestada ultrapassasse uma região de MPU.

• Falhando com Hubris

  • Várias coisas deixaram de acontecer quando o sistema falhou.
  • Foi possível consertar o switch de rede quebrado em 3 horas.
  • Isolamento de falhas, falha segura, memória compartilhada segura, co-design entre kernel e depurador, simplicidade de projeto e implementação, e a integração próxima e não hierárquica da equipe ajudaram.

Opinião do GN⁺

• Este artigo mostra, por meio do processo de encontrar e corrigir um bug no sistema operacional Hubris, a importância de um projeto de software robusto mesmo em sistemas complexos.
• O processo de descoberta e correção do bug destaca a importância do trabalho em equipe e de ferramentas de depuração eficientes para resolver problemas complexos de engenharia de software.
• Ao usar sistemas como o Hubris, ele mostra o quanto os recursos de isolamento e gerenciamento de falhas são importantes. Isso pode melhorar bastante a estabilidade e a manutenibilidade do sistema.
• O artigo também mostra como usar uma linguagem segura como Rust para garantir segurança de memória e minimizar bugs. Em sistemas que usam Rust, esse tipo de bug ocorre raramente, o que demonstra na prática o quão eficazes são as garantias de segurança de memória do Rust.
• Outros projetos ou produtos com funcionalidades semelhantes incluem seL4, FreeRTOS e Zephyr, que são sistemas operacionais embarcados com objetivos e características diferentes.
• Ao adotar sistemas como o Hubris, é preciso considerar fatores como restrições de memória, gerenciamento de tarefas e o projeto do mecanismo de IPC. As vantagens de escolher esse tipo de sistema estão em um projeto robusto e no gerenciamento seguro de memória, enquanto as desvantagens podem ser a complexidade do sistema e a curva de aprendizado.

[GN⁺]

Comentários do Hacker News

• Review do código do kernel do Hubris

  • Li o código do kernel do Hubris por meia hora, e ele é muito claro e bem escrito. É nitidamente diferente do código em C com macros complexas, variáveis de duas letras e poucos comentários que já vi antes. Recomendo como uma boa leitura antes de dormir.

• Elogio ao anúncio de vaga

  • Este é um dos melhores anúncios de vaga que já vi. Há uma transição natural para a cultura da empresa, seguida no final por um “estamos contratando”. É até um excelente post-mortem que desenvolvedores de nível de aplicação conseguem entender. Como estou estudando Rust agora, eu estava preparado para esse tipo de conteúdo. Além disso, é sempre um prazer ver o trabalho de outra pessoa com muitos comentários no código.

• Review de código e sugestão

  • Uma observação rápida sobre o código: como se trata de um comentário sobre a invariante de um campo que todos os autores devem respeitar e todos os leitores podem usar, e não sobre os detalhes de uma função específica, seria melhor adicioná-lo à string de documentação de TaskDesc::regions.

• Avaliação do processo de depuração

  • O texto oferece uma análise profunda da depuração de um problema complexo, e o fato de o restante do sistema ter permanecido estável é uma prova do trabalho de engenharia de alta qualidade da equipe da Oxide. Pessoalmente, isso me inspirou a aplicar técnicas semelhantes no trabalho.

• Interesse pela cultura da equipe da Oxide

  • A equipe de engenharia da Oxide não é isolada internamente e tem uma cultura que incentiva abertura, curiosidade e comunicação, ao mesmo tempo que desencoraja atitudes defensivas, construção de impérios e gatekeeping. Eles se esforçaram para criar e manter essa cultura, e isso pode ser visto na forma como se organizam horizontalmente, atravessando o que em outras organizações seria considerado o limite entre equipes. Gostaria de saber mais sobre a motivação para criar essa cultura e os detalhes concretos de sua execução. Há desvantagens em incentivar “abertura, curiosidade e comunicação” dentro da organização? Existem casos em que se opta por um sistema hierárquico mais rígido? Parece que o organograma deveria ser decidido estrategicamente, mas não conheço bem os trade-offs envolvidos.

• Link de informações relacionadas

  • As informações prévias podem ser encontradas pelo link fornecido.

• Empatia com problemas que surgem durante a depuração

  • Concordo que travamentos aleatórios que desaparecem quando você adiciona código de depuração são os piores.

• Sugestão sobre o tratamento de hardware

  • Menciona-se que seria possível oferecer suporte a mais de 8 regiões tratando o hardware como uma TLB soft-fill.

• Elogio ao trabalho da Oxide

  • Expressa admiração pelo trabalho realizado pela Oxide.

• Reação ao nome do sistema operacional

  • Demonstra surpresa e reação ao fato de o sistema operacional se chamar Hubris.