GN⁺: 네트워크 스위치를 죽인 범인은? '허브리스 버그' 이야기

Hubris 버그 이야기: 네트워크 스위치를 죽인 것은 누구인가?

• Hubris란 무엇인가?

  • Hubris는 깊이 내장된 시스템을 위한 운영체제로, 키보드 내부와 같은 컴퓨터로 인식되지 않는 컴퓨터들을 위해 설계됨.
  • Oxide Rack에서 큰 프로세서를 시작하는 데 필요한 모든 작업을 처리하기 위해 개발됨.
  • Hubris는 상당히 독특한데, 이야기에 관련된 부분은 아래에서 설명됨.

• 범죄 현장

  • Oxide의 네트워크 스위치 펌웨어를 담당하는 동료 Arjen Roodselaar이 전원 순서와 클록 구성에 대한 변경을 테스트 중이었음.
  • 작은 변경 후 갑자기 스위치가 켜지지 않게 됨.
  • 펌웨어의 일부는 응답했지만, 전원 공급 순서를 담당하는 중요한 부분은 멈춰 있었음.

• 제한된 RAM에서 더 많은 것을 끌어내기

  • Hubris를 사용하는 저렴한 마이크로컨트롤러는 RAM과 플래시가 매우 제한적임.
  • Hubris는 작업이라고 불리는 별도로 컴파일된 많은 프로그램으로 구성되어 있어, 다른 운영체제보다 약간 더 높은 자원 요구 사항을 가짐.
  • 동료 Matt Keeter는 최근 시스템을 더 똑똑하게 만들어 여러 개의 2의 제곱 영역을 사용하여 가능한 한 작업을 포장하려고 시도함.

• 연기가 나는 총구

  • Arjen은 Humility라는 Hubris 디버거를 사용하여 실패한 네트워크 스위치를 조사함.
  • humility tasks 명령어를 사용하여 프로세서에서 실행 중인 작업 목록과 상태 정보를 출력함.
  • 전원 순서를 담당하는 작업이 메모리 장애로 인해 115번 재시작되었다는 것을 발견함.

• Hubris IPC에서 Rust 대출을 작업 간에 확장

  • Hubris 작업은 IPC를 통해 서로 메시지를 주고받을 수 있음.
  • 메시지는 함수 호출과 매우 유사하게 보이고 동작함.
  • 작업이 메모리를 다른 작업에 대출할 때, 실제로 소유하지 않은 메모리를 대출하려고 하면 안 됨.

• 기능이 공격할 때

  • 두 가지 기능이 결합하여 버그가 될 수 있음.
  • 작업 포장은 빌드 시스템에서 기회주의적으로 작동함.
  • 작업 A의 크기가 약간 변경되면 관련 없는 작업 B의 MPU 영역 경계 위치가 이동할 수 있음.

• 내부에서 걸려오는 전화!

  • 메모리 보호 알고리즘을 변경해야 함.
  • 대출된 메모리가 MPU 영역을 넘어가도록 허용해야 함.

• Hubris로 실패하기

  • 시스템이 실패했을 때 발생하지 않은 여러 가지 사항들.
  • 고장난 네트워크 스위치를 3시간 만에 고칠 수 있었음.
  • 고장 격리, 안전을 향한 실패, 안전한 공유 메모리, 커널-디버거 공동 설계, 설계 및 구현의 단순성, 팀의 긴밀한 비계층적 통합 등이 도움이 됨.

GN⁺의 의견

• 이 기사는 Hubris라는 운영체제에서 발생한 버그를 찾아내고 해결하는 과정을 통해, 복잡한 시스템에서도 견고한 소프트웨어 설계의 중요성을 보여줌.
• 버그 발견과 해결 과정은 소프트웨어 엔지니어링의 복잡한 문제를 해결하는 데 있어 팀워크와 효율적인 디버깅 도구의 중요성을 강조함.
• Hubris와 같은 시스템을 사용할 때, 시스템의 격리와 장애 관리 기능이 얼마나 중요한지를 보여줌. 이는 시스템의 안정성과 유지보수성을 크게 향상시킬 수 있음.
• 이 기사는 또한 안전한 프로그래밍 언어인 Rust를 사용하여 메모리 안전성을 보장하고 버그를 최소화하는 방법을 보여줌. Rust를 사용하는 시스템에서는 이러한 유형의 버그가 드물게 발생하며, 이는 Rust의 메모리 안전성 보장이 실제로 얼마나 효과적인지를 입증함.
• 비슷한 기능을 가진 다른 프로젝트나 제품으로는 seL4, FreeRTOS, Zephyr 등이 있으며, 이들은 각각 다른 목적과 특성을 가진 임베디드 시스템 운영체제임.
• Hubris와 같은 시스템을 도입할 때는 메모리 제약, 태스크 관리, IPC 메커니즘의 설계와 같은 요소들을 고려해야 함. 이러한 시스템을 선택함으로써 얻는 이점은 견고한 시스템 설계와 안전한 메모리 관리에 있으며, 단점은 시스템의 복잡성과 학습 곡선이 될 수 있음.

[neo]

Hacker News 의견

• Hubris 커널 코드 리뷰

  • Hubris의 커널 코드를 반 시간 동안 읽어보았는데, 매우 명확하고 잘 작성되어 있음. 이전에 보았던 복잡한 매크로와 두 글자 변수명, 주석이 부족한 C 코드와는 확연히 다름. 잠자기 전 읽기에 좋은 자료임을 추천함.

• 직무 광고에 대한 칭찬

  • 이것은 본인이 본 최고의 직무 광고 중 하나임. 문화에 대한 자연스러운 전환과 마지막에 "우리는 채용 중입니다"라는 말이 이어짐. 심지어 애플리케이션 수준의 개발자도 이해할 수 있는 훌륭한 사후 분석(post-mortem)임. 현재 Rust를 공부 중이라 이런 내용에 대한 준비가 되어 있었음. 또한, 코드에 많은 주석을 달아놓은 다른 사람의 작업을 보는 것은 언제나 즐거움.

• 코드 리뷰 및 제안

  • 코드에 대한 간단한 지적: 특정 함수의 세부 사항이 아니라 모든 작성자가 존중해야 하고 모든 독자가 이용할 수 있는 필드의 불변성(invariant)에 대한 주석이므로, TaskDesc::regions 문서 문자열에 추가하는 것이 좋을 것임.

• 디버깅 과정에 대한 평가

  • 복잡한 문제를 디버깅하는 깊이 있는 분석을 제공하며, 시스템의 나머지 부분이 안정적으로 유지된 것은 Oxide 팀의 고품질 엔지니어링 작업의 증거임. 개인적으로 이에 영감을 받아 직장에서 비슷한 기술을 적용할 계획임.

• Oxide 팀의 문화에 대한 관심

  • Oxide의 엔지니어링 팀은 내부적으로 격리되어 있지 않으며, 개방성, 호기심, 커뮤니케이션을 장려하고 방어적 태도, 제국 건설, 게이트키핑을 억제하는 문화를 가지고 있음. 이러한 문화를 만들고 지키기 위해 노력했으며, 다른 조직에서 팀이라고 부를 범위를 가로질러 수평적으로 조직된 방식에서 이를 볼 수 있음. 이러한 문화를 만들기 위한 동기와 구체적인 실행 세부 사항에 대해 더 알고 싶음. 조직 내에서 "개방성, 호기심, 커뮤니케이션"을 장려하는 것의 단점이 있는지, 더 엄격한 계층적 시스템을 선택하는 경우가 있는지, 조직도가 전략적으로 결정되어야 한다는 생각이 들지만, 그에 대한 트레이드오프는 잘 모르겠음.

• 관련 정보 링크

  • 사전 정보는 주어진 링크를 통해 찾을 수 있음.

• 디버깅 시 발생하는 문제에 대한 공감

  • 디버깅 코드를 추가하면 사라지는 무작위 충돌은 최악의 충돌임에 공감함.

• 하드웨어 처리에 대한 제안

  • 하드웨어를 소프트 필 TLB처럼 처리함으로써 8개 이상의 영역을 지원할 수 있음을 언급함.

• Oxide의 작업에 대한 칭찬

  • Oxide가 수행하는 작업에 대해 놀라움을 표함.

• 운영체제 이름에 대한 반응

  • 운영체제의 이름을 Hubris라고 지은 것에 대해 놀라움과 반응을 보임.