ใครคือคนร้ายที่ฆ่าสวิตช์เครือข่าย? เรื่องราวของบั๊ก 'Hubris'

เรื่องราวของบั๊ก Hubris: ใครกันที่ทำให้สวิตช์เครือข่ายพัง?

• Hubris คืออะไร?

  • Hubris เป็นระบบปฏิบัติการสำหรับระบบฝังตัวเชิงลึก ออกแบบมาสำหรับคอมพิวเตอร์ที่ไม่ได้ถูกมองว่าเป็นคอมพิวเตอร์ เช่น ภายในคีย์บอร์ด
  • มันถูกพัฒนาขึ้นเพื่อจัดการทุกอย่างที่จำเป็นต่อการเริ่มต้นโปรเซสเซอร์ขนาดใหญ่ใน Oxide Rack
  • Hubris ค่อนข้างมีเอกลักษณ์เฉพาะตัว โดยส่วนที่เกี่ยวข้องกับเรื่องนี้จะอธิบายด้านล่าง

• ที่เกิดเหตุ

  • Arjen Roodselaar เพื่อนร่วมงานผู้รับผิดชอบเฟิร์มแวร์ของสวิตช์เครือข่ายที่ Oxide กำลังทดสอบการเปลี่ยนแปลงเกี่ยวกับลำดับการจ่ายไฟและการตั้งค่านาฬิกา
  • หลังจากการเปลี่ยนแปลงเล็กน้อย สวิตช์ก็เปิดไม่ติดขึ้นมาอย่างกะทันหัน
  • เฟิร์มแวร์บางส่วนยังตอบสนองอยู่ แต่ส่วนสำคัญที่ดูแลลำดับการจ่ายไฟกลับหยุดทำงาน

• ดึงประสิทธิภาพให้ได้มากขึ้นจาก RAM ที่มีจำกัด

  • ไมโครคอนโทรลเลอร์ราคาประหยัดที่ใช้ Hubris มี RAM และแฟลชที่จำกัดมาก
  • Hubris ประกอบด้วยโปรแกรมจำนวนมากที่คอมไพล์แยกจากกันและเรียกว่า task ทำให้มีความต้องการทรัพยากรสูงกว่าระบบปฏิบัติการอื่นเล็กน้อย
  • Matt Keeter เพื่อนร่วมงานเพิ่งทำให้ระบบฉลาดขึ้น โดยพยายามแพ็ก task ให้แน่นที่สุดเท่าที่จะทำได้ด้วยการใช้หลายพื้นที่ขนาดกำลังสอง

• หลักฐานชิ้นสำคัญ

  • Arjen ใช้ดีบักเกอร์ของ Hubris ที่ชื่อ Humility เพื่อตรวจสอบสวิตช์เครือข่ายที่ล้มเหลว
  • เขาใช้คำสั่ง humility tasks เพื่อพิมพ์รายการ task ที่กำลังรันอยู่บนโปรเซสเซอร์พร้อมข้อมูลสถานะ
  • และพบว่า task ที่รับผิดชอบลำดับการจ่ายไฟถูกรีสตาร์ตไปแล้ว 115 ครั้งเนื่องจาก memory fault

• ขยายการยืมแบบ Rust ไปข้าม task ใน Hubris IPC

  • task ของ Hubris สามารถส่งข้อความหากันผ่าน IPC ได้
  • ข้อความเหล่านี้มีลักษณะและการทำงานคล้ายกับการเรียกฟังก์ชันมาก
  • เมื่อ task หนึ่งยืมหน่วยความจำให้กับอีก task ก็ไม่ควรพยายามยืมหน่วยความจำที่ตัวเองไม่ได้เป็นเจ้าของจริง

• เมื่อฟีเจอร์หันกลับมาโจมตี

  • ฟีเจอร์สองอย่างสามารถรวมกันจนกลายเป็นบั๊กได้
  • การแพ็ก task ทำงานแบบฉวยโอกาสในระบบบิลด์
  • หากขนาดของ task A เปลี่ยนไปเล็กน้อย ตำแหน่งขอบเขตของพื้นที่ MPU ของ task B ที่ไม่เกี่ยวข้องกันก็อาจเลื่อนไปได้

• สายเรียกเข้าจากข้างใน!

  • จำเป็นต้องเปลี่ยนอัลกอริทึมการป้องกันหน่วยความจำ
  • ต้องยอมให้หน่วยความจำที่ถูกยืมข้ามขอบเขตของพื้นที่ MPU ได้

• การล้มเหลวอย่างมีระบบด้วย Hubris

  • มีหลายสิ่งที่ไม่ได้เกิดขึ้นเมื่อระบบล้มเหลว
  • พวกเขาซ่อมสวิตช์เครือข่ายที่พังได้ภายใน 3 ชั่วโมง
  • การแยกความเสียหาย การล้มเหลวไปสู่สถานะปลอดภัย หน่วยความจำที่ใช้ร่วมกันอย่างปลอดภัย การออกแบบร่วมกันระหว่างเคอร์เนลกับดีบักเกอร์ ความเรียบง่ายของการออกแบบและการใช้งาน และการบูรณาการกันอย่างใกล้ชิดแบบไม่ยึดลำดับชั้นของทีม ล้วนช่วยได้

ความเห็นของ GN⁺

• บทความนี้แสดงให้เห็นถึงความสำคัญของการออกแบบซอฟต์แวร์ที่แข็งแกร่ง แม้ในระบบที่ซับซ้อน ผ่านกระบวนการค้นหาและแก้ไขบั๊กที่เกิดขึ้นในระบบปฏิบัติการชื่อ Hubris
• กระบวนการค้นหาและแก้บั๊กเน้นย้ำถึงความสำคัญของการทำงานเป็นทีมและเครื่องมือดีบักที่มีประสิทธิภาพในการแก้ปัญหาทางวิศวกรรมซอฟต์แวร์ที่ซับซ้อน
• มันยังแสดงให้เห็นว่าฟังก์ชันด้านการแยกส่วนของระบบและการจัดการความขัดข้องมีความสำคัญเพียงใดเมื่อใช้งานระบบอย่าง Hubris ซึ่งช่วยยกระดับเสถียรภาพและความสามารถในการบำรุงรักษาของระบบได้มาก
• บทความนี้ยังแสดงให้เห็นวิธีใช้ภาษาโปรแกรมที่ปลอดภัยอย่าง Rust เพื่อรับประกันความปลอดภัยของหน่วยความจำและลดบั๊กให้เหลือน้อยที่สุด ในระบบที่ใช้ Rust บั๊กประเภทนี้เกิดขึ้นได้ไม่บ่อย ซึ่งเป็นหลักฐานว่าการรับประกันด้าน memory safety ของ Rust มีประสิทธิภาพเพียงใดในทางปฏิบัติ
• โครงการหรือผลิตภัณฑ์อื่นที่มีลักษณะคล้ายกัน ได้แก่ seL4, FreeRTOS และ Zephyr ซึ่งล้วนเป็นระบบปฏิบัติการสำหรับระบบฝังตัวที่มีเป้าหมายและคุณลักษณะแตกต่างกัน
• เมื่อนำระบบอย่าง Hubris มาใช้ ควรพิจารณาปัจจัยต่าง ๆ เช่น ข้อจำกัดด้านหน่วยความจำ การจัดการ task และการออกแบบกลไก IPC ข้อดีของการเลือกระบบลักษณะนี้คือการออกแบบระบบที่แข็งแกร่งและการจัดการหน่วยความจำอย่างปลอดภัย ส่วนข้อเสียอาจเป็นความซับซ้อนของระบบและเส้นโค้งการเรียนรู้

[GN⁺]

ความคิดเห็นจาก Hacker News

• รีวิวโค้ดเคอร์เนล Hubris

  • ลองอ่านโค้ดเคอร์เนลของ Hubris อยู่ครึ่งชั่วโมง พบว่าชัดเจนมากและเขียนมาอย่างดีมาก แตกต่างอย่างชัดเจนจากโค้ด C ที่เคยเห็นก่อนหน้านี้ซึ่งเต็มไปด้วยแมโครซับซ้อน ชื่อตัวแปรสองตัวอักษร และคอมเมนต์ที่ไม่เพียงพอ ขอแนะนำว่าเป็นงานอ่านก่อนนอนที่ดีมาก

• ชื่นชมประกาศรับสมัครงาน

  • นี่คือหนึ่งในประกาศรับสมัครงานที่ดีที่สุดเท่าที่เคยเห็นมา การเปลี่ยนผ่านไปสู่เรื่องวัฒนธรรมทำได้อย่างเป็นธรรมชาติ และลงท้ายด้วยคำว่า "เรากำลังรับสมัคร" อีกทั้งยังเป็น post-mortem ที่ยอดเยี่ยมซึ่งแม้แต่นักพัฒนาระดับแอปพลิเคชันก็เข้าใจได้ พอดีกำลังเรียน Rust อยู่จึงพร้อมรับเนื้อหาแบบนี้อยู่แล้ว นอกจากนี้ การได้เห็นงานของคนอื่นที่ใส่คอมเมนต์ไว้ในโค้ดมากมายก็เป็นเรื่องน่ายินดีเสมอ

• รีวิวโค้ดและข้อเสนอแนะ

  • มีข้อสังเกตสั้น ๆ เกี่ยวกับโค้ด: เพราะนี่ไม่ใช่รายละเอียดของฟังก์ชันใดฟังก์ชันหนึ่ง แต่เป็นคอมเมนต์เกี่ยวกับ invariant ของฟิลด์ที่ผู้เขียนทุกคนควรเคารพและผู้อ่านทุกคนควรเข้าถึงได้ จึงน่าจะเหมาะกว่าถ้าเพิ่มไว้ในสตริงเอกสารของ TaskDesc::regions

• ประเมินกระบวนการดีบัก

  • บทความนี้นำเสนอการวิเคราะห์เชิงลึกของการดีบักปัญหาที่ซับซ้อน และการที่ส่วนที่เหลือของระบบยังคงเสถียรได้ก็เป็นหลักฐานถึงงานวิศวกรรมคุณภาพสูงของทีม Oxide โดยส่วนตัวได้รับแรงบันดาลใจจากเรื่องนี้และตั้งใจจะนำเทคนิคคล้ายกันไปใช้ที่ทำงาน

• ความสนใจต่อวัฒนธรรมของทีม Oxide

  • ทีมวิศวกรรมของ Oxide ไม่ได้แยกตัวอยู่ภายใน แต่มีวัฒนธรรมที่ส่งเสริมความเปิดกว้าง ความใฝ่รู้ และการสื่อสาร พร้อมทั้งยับยั้งท่าทีตั้งรับ การสร้างอาณาจักรของตัวเอง และการกีดกันคนอื่น พวกเขาทุ่มเทเพื่อสร้างและรักษาวัฒนธรรมนี้ไว้ และสามารถมองเห็นได้จากรูปแบบการจัดองค์กรในแนวนอนที่พาดข้ามขอบเขตซึ่งองค์กรอื่นอาจเรียกว่าเป็นทีม อยากรู้เพิ่มเติมเกี่ยวกับแรงจูงใจและรายละเอียดการลงมือทำที่เป็นรูปธรรมเพื่อสร้างวัฒนธรรมแบบนี้ อยากรู้ด้วยว่าการส่งเสริม "ความเปิดกว้าง ความใฝ่รู้ และการสื่อสาร" ภายในองค์กรมีข้อเสียอะไรบ้าง หรือมีกรณีใดที่ควรเลือกระบบลำดับชั้นที่เข้มงวดกว่านี้ รู้สึกว่าแผนผังองค์กรควรถูกกำหนดเชิงกลยุทธ์ แต่ยังไม่ค่อยเข้าใจ trade-off ของมัน

• ลิงก์ข้อมูลที่เกี่ยวข้อง

  • สามารถดูข้อมูลเบื้องต้นได้จากลิงก์ที่ให้ไว้

• เห็นด้วยกับปัญหาที่เกิดขึ้นระหว่างการดีบัก

  • เห็นด้วยว่าการแครชแบบสุ่มที่หายไปทันทีเมื่อเพิ่มโค้ดดีบักเข้าไปนั้นเป็นการแครชที่แย่ที่สุด

• ข้อเสนอเกี่ยวกับการจัดการฮาร์ดแวร์

  • มีการกล่าวว่าสามารถรองรับได้มากกว่า 8 รีเจียนโดยจัดการฮาร์ดแวร์ให้เหมือน soft-filled TLB

• ชื่นชมงานของ Oxide

  • แสดงความทึ่งต่อผลงานที่ Oxide ทำ

• ปฏิกิริยาต่อชื่อระบบปฏิบัติการ

  • แสดงความประหลาดใจและปฏิกิริยาต่อการตั้งชื่อระบบปฏิบัติการว่า Hubris