Siapa pelaku yang melumpuhkan switch jaringan? Kisah 'bug Hubris'

Kisah bug Hubris: siapa yang melumpuhkan switch jaringan?

• Apa itu Hubris?

  • Hubris adalah sistem operasi untuk sistem yang sangat tertanam, dirancang untuk komputer yang tidak dikenali sebagai komputer, seperti bagian dalam keyboard.
  • Dikembangkan untuk menangani semua pekerjaan yang diperlukan guna menyalakan prosesor besar di Oxide Rack.
  • Hubris cukup unik, dan bagian yang relevan dengan cerita ini dijelaskan di bawah.

• TKP

  • Rekan di Oxide, Arjen Roodselaar, yang menangani firmware switch jaringan, sedang menguji perubahan pada urutan daya dan konfigurasi clock.
  • Setelah perubahan kecil, switch tiba-tiba tidak bisa menyala.
  • Sebagian firmware masih merespons, tetapi bagian penting yang menangani urutan catu daya berhenti.

• Memeras lebih banyak dari RAM yang terbatas

  • Mikrokontroler murah yang menggunakan Hubris memiliki RAM dan flash yang sangat terbatas.
  • Hubris terdiri dari banyak program yang dikompilasi terpisah yang disebut task, sehingga kebutuhan sumber dayanya sedikit lebih tinggi dibanding sistem operasi lain.
  • Rekan Matt Keeter baru-baru ini membuat sistem lebih cerdas dengan mencoba mengemas task seefisien mungkin menggunakan beberapa region berpangkat dua.

• Barang bukti yang tak terbantahkan

  • Arjen menyelidiki switch jaringan yang gagal menggunakan debugger Hubris bernama Humility.
  • Ia menggunakan perintah humility tasks untuk menampilkan daftar task yang berjalan di prosesor beserta informasi statusnya.
  • Ia menemukan bahwa task yang menangani urutan daya telah restart 115 kali akibat gangguan memori.

• Memperluas borrow Rust antar-task dalam IPC Hubris

  • Task Hubris dapat saling mengirim pesan melalui IPC.
  • Pesan tersebut terlihat dan bekerja sangat mirip dengan pemanggilan fungsi.
  • Ketika sebuah task meminjamkan memori ke task lain, task itu tidak boleh mencoba meminjamkan memori yang sebenarnya tidak dimilikinya.

• Saat fitur berbalik menyerang

  • Dua fitur dapat bergabung dan menjadi bug.
  • Pengemasan task bekerja secara oportunistis di sistem build.
  • Jika ukuran task A berubah sedikit, posisi batas region MPU milik task B yang tidak terkait bisa ikut bergeser.

• Telepon dari dalam rumah!

  • Algoritma perlindungan memori perlu diubah.
  • Memori yang dipinjamkan harus diizinkan melintasi region MPU.

• Gagal dengan Hubris

  • Ada banyak hal yang tidak terjadi ketika sistem gagal.
  • Switch jaringan yang rusak bisa diperbaiki dalam 3 jam.
  • Isolasi kerusakan, gagal menuju kondisi aman, memori bersama yang aman, ko-desain kernel-debugger, kesederhanaan desain dan implementasi, serta integrasi tim yang erat dan non-hierarkis semuanya membantu.

Opini GN⁺

• Artikel ini menunjukkan pentingnya desain perangkat lunak yang tangguh bahkan dalam sistem yang kompleks, melalui proses menemukan dan menyelesaikan bug yang terjadi pada sistem operasi bernama Hubris.
• Proses penemuan dan penyelesaian bug menekankan pentingnya kerja tim dan alat debugging yang efisien dalam memecahkan masalah rumit di rekayasa perangkat lunak.
• Artikel ini menunjukkan betapa pentingnya fitur isolasi sistem dan penanganan kegagalan saat menggunakan sistem seperti Hubris. Hal ini dapat sangat meningkatkan stabilitas dan kemudahan pemeliharaan sistem.
• Artikel ini juga menunjukkan bagaimana bahasa pemrograman aman seperti Rust digunakan untuk menjamin keamanan memori dan meminimalkan bug. Pada sistem yang menggunakan Rust, bug jenis ini jarang terjadi, yang membuktikan betapa efektifnya jaminan keamanan memori Rust dalam praktik.
• Proyek atau produk lain dengan fitur serupa antara lain seL4, FreeRTOS, dan Zephyr, yang masing-masing merupakan sistem operasi embedded dengan tujuan dan karakteristik berbeda.
• Saat mengadopsi sistem seperti Hubris, perlu mempertimbangkan faktor seperti keterbatasan memori, manajemen task, dan desain mekanisme IPC. Keuntungan memilih sistem semacam ini terletak pada desain sistem yang tangguh dan pengelolaan memori yang aman, sedangkan kekurangannya bisa berupa kompleksitas sistem dan kurva belajar yang curam.

[GN⁺]

Komentar Hacker News

• Ulasan kode kernel Hubris

  • Saya membaca kode kernel Hubris selama sekitar setengah jam, dan kodenya sangat jelas serta ditulis dengan baik. Sangat berbeda dibanding kode C yang pernah saya lihat sebelumnya, yang penuh makro rumit, nama variabel dua huruf, dan minim komentar. Saya merekomendasikannya sebagai bacaan yang cocok sebelum tidur.

• Pujian untuk iklan lowongan kerja

  • Ini adalah salah satu iklan lowongan kerja terbaik yang pernah saya lihat. Transisinya ke pembahasan budaya terasa alami, lalu ditutup dengan kalimat "kami sedang merekrut". Bahkan ini juga merupakan post-mortem yang sangat bagus dan bisa dipahami oleh developer tingkat aplikasi. Saya kebetulan sedang belajar Rust, jadi cukup siap mengikuti isi seperti ini. Selain itu, selalu menyenangkan melihat hasil kerja orang lain yang diberi banyak komentar di kodenya.

• Ulasan kode dan saran

  • Sedikit catatan tentang kodenya: karena ini bukan detail fungsi tertentu, melainkan komentar tentang invariant field yang harus dihormati oleh semua penulis dan bisa dimanfaatkan oleh semua pembaca, akan lebih baik jika ditambahkan ke docstring TaskDesc::regions.

• Penilaian terhadap proses debugging

  • Ini memberikan analisis mendalam tentang proses debugging masalah yang rumit, dan fakta bahwa bagian sistem lainnya tetap stabil menjadi bukti kualitas engineering yang tinggi dari tim Oxide. Secara pribadi saya terinspirasi olehnya dan berencana menerapkan teknik serupa di tempat kerja.

• Ketertarikan pada budaya tim Oxide

  • Tim engineering Oxide tidak terisolasi secara internal, dan tampaknya memiliki budaya yang mendorong keterbukaan, rasa ingin tahu, dan komunikasi, sambil menekan sikap defensif, pembangunan kerajaan, dan gatekeeping. Mereka jelas telah berupaya membangun dan menjaga budaya itu, dan hal tersebut terlihat dari cara mereka diorganisasi secara horizontal melintasi cakupan yang di organisasi lain biasanya disebut tim. Saya ingin tahu lebih banyak tentang motivasi dan detail implementasi konkretnya untuk membangun budaya semacam itu. Apakah ada sisi negatif dari mendorong "keterbukaan, rasa ingin tahu, dan komunikasi" di dalam organisasi, atau situasi di mana sistem hierarkis yang lebih ketat justru dipilih? Rasanya bagan organisasi memang harus diputuskan secara strategis, tetapi saya belum begitu memahami trade-off-nya.

• Tautan informasi terkait

  • Informasi latar belakang dapat ditemukan melalui tautan yang diberikan.

• Empati terhadap masalah yang muncul saat debugging

  • Saya setuju bahwa crash acak yang menghilang saat kode debugging ditambahkan adalah jenis crash yang paling menyebalkan.

• Saran tentang penanganan hardware

  • Disebutkan bahwa lebih dari 8 region bisa didukung dengan memperlakukan hardware seperti soft-fill TLB.

• Pujian untuk pekerjaan Oxide

  • Mengungkapkan kekaguman atas pekerjaan yang dilakukan oleh Oxide.

• Reaksi terhadap nama sistem operasi

  • Menunjukkan keterkejutan dan reaksi terhadap penamaan sistem operasi sebagai Hubris.