नेटवर्क स्विच को किसने मारा? 'Hubris bug' की कहानी

Hubris bug की कहानी: नेटवर्क स्विच को किसने मारा?

• Hubris क्या है?

  • Hubris गहराई से embedded systems के लिए एक operating system है, जिसे ऐसे computers के लिए डिज़ाइन किया गया है जिन्हें आम तौर पर computer के रूप में नहीं पहचाना जाता, जैसे कि keyboard के अंदर का computer.
  • इसे Oxide Rack में बड़े processors को शुरू करने के लिए ज़रूरी सभी काम संभालने हेतु विकसित किया गया था.
  • Hubris काफ़ी अनोखा है, और इस कहानी से जुड़े हिस्सों को नीचे समझाया गया है.

• अपराध स्थल

  • Oxide के network switch firmware पर काम करने वाले सहयोगी Arjen Roodselaar power sequencing और clock configuration में बदलावों का परीक्षण कर रहे थे.
  • एक छोटे बदलाव के बाद अचानक switch चालू होना बंद हो गया.
  • firmware का कुछ हिस्सा जवाब दे रहा था, लेकिन power supply sequence संभालने वाला महत्वपूर्ण हिस्सा रुका हुआ था.

• सीमित RAM से ज़्यादा हासिल करना

  • Hubris चलाने वाले सस्ते microcontrollers में RAM और flash बहुत सीमित होती है.
  • Hubris कई अलग-अलग compile किए गए programs से बना है, जिन्हें tasks कहा जाता है, इसलिए इसकी resource requirements दूसरे operating systems की तुलना में थोड़ी अधिक हैं.
  • सहयोगी Matt Keeter ने हाल ही में system को और स्मार्ट बनाया ताकि वह कई power-of-two regions का उपयोग करके tasks को जितना संभव हो उतना अच्छी तरह पैक करने की कोशिश करे.

• धुआँ छोड़ती बंदूक

  • Arjen ने Humility नाम के Hubris debugger का उपयोग करके fail हुए network switch की जाँच की.
  • humility tasks कमांड का उपयोग करके उन्होंने processor पर चल रहे tasks की सूची और उनकी status information निकाली.
  • उन्होंने पाया कि power sequencing संभालने वाला task memory fault के कारण 115 बार restart हो चुका था.

• Hubris IPC में Rust borrow को tasks के बीच बढ़ाना

  • Hubris tasks IPC के ज़रिए एक-दूसरे को messages भेज सकते हैं.
  • ये messages function calls की तरह दिखते और काम करते हैं.
  • जब कोई task memory को दूसरे task को borrow पर देता है, तो उसे ऐसी memory borrow पर देने की कोशिश नहीं करनी चाहिए जिसका वह वास्तव में मालिक नहीं है.

• जब features हमला करते हैं

  • दो features मिलकर bug बन सकते हैं.
  • task packing build system में अवसरवादी तरीके से काम करती है.
  • अगर task A का आकार थोड़ा बदल जाए, तो असंबंधित task B की MPU region boundary की स्थिति भी खिसक सकती है.

• अंदर से फ़ोन आ रहा है!

  • memory protection algorithm को बदलने की ज़रूरत थी.
  • borrowed memory को MPU region के पार जाने की अनुमति देनी थी.

• Hubris के साथ fail होना

  • system fail होने पर कई बुरी चीज़ें नहीं हुईं.
  • खराब हुए network switch को 3 घंटे में ठीक किया जा सका.
  • fault isolation, fail-safe behavior, safe shared memory, kernel-debugger co-design, design और implementation की सादगी, और टीम का क़रीबी non-hierarchical integration—इन सबने मदद की.

GN⁺ की राय

• यह लेख Hubris नाम के operating system में आए एक bug को खोजने और हल करने की प्रक्रिया के ज़रिए दिखाता है कि जटिल systems में भी मज़बूत software design कितना महत्वपूर्ण है.
• bug को खोजने और ठीक करने की प्रक्रिया software engineering की जटिल समस्याओं को सुलझाने में teamwork और प्रभावी debugging tools के महत्व को रेखांकित करती है.
• यह दिखाता है कि Hubris जैसे systems का उपयोग करते समय system isolation और fault handling capabilities कितनी महत्वपूर्ण होती हैं. इससे system stability और maintainability में काफ़ी सुधार हो सकता है.
• यह लेख यह भी दिखाता है कि Rust जैसी safe programming language का उपयोग करके memory safety कैसे सुनिश्चित की जा सकती है और bugs को कैसे कम किया जा सकता है. Rust का उपयोग करने वाले systems में इस तरह के bugs कम ही होते हैं, और यह दिखाता है कि Rust की memory safety guarantees व्यवहार में कितनी प्रभावी हैं.
• समान capabilities वाले अन्य projects या products में seL4, FreeRTOS, Zephyr आदि शामिल हैं, जो अलग-अलग उद्देश्यों और विशेषताओं वाले embedded system operating systems हैं.
• Hubris जैसे systems अपनाते समय memory constraints, task management, और IPC mechanism के design जैसे कारकों पर विचार करना चाहिए. ऐसे systems चुनने के फ़ायदे मज़बूत system design और safe memory management में हैं, जबकि कमियाँ system complexity और learning curve हो सकती हैं.

[GN⁺]

Hacker News की राय

• Hubris kernel code review

  • Hubris का kernel code मैंने करीब आधे घंटे तक पढ़ा, और यह बहुत स्पष्ट तथा अच्छी तरह लिखा हुआ है। यह पहले देखे गए जटिल macros, दो-अक्षर वाले variable names, और कम comments वाले C code से बिल्कुल अलग है। सोने से पहले पढ़ने के लिए इसे सुझाऊँगा/सुझाऊँगी।

• जॉब विज्ञापन की प्रशंसा

  • यह मेरे द्वारा देखे गए सबसे बेहतरीन job ads में से एक है। संस्कृति पर स्वाभाविक रूप से बात आती है और अंत में "हम hiring कर रहे हैं" से जुड़ती है। यह application-level developers के लिए भी समझ में आने वाला शानदार post-mortem है। मैं अभी Rust पढ़ रहा/रही हूँ, इसलिए ऐसे विषय के लिए तैयार था/थी। साथ ही, किसी और के काम में बहुत सारे comments देखना हमेशा अच्छा लगता है।

• Code review और सुझाव

  • code पर एक छोटा-सा point: यह किसी खास function की detail नहीं, बल्कि उन fields के invariant पर comment है जिन्हें सभी authors को respect करना चाहिए और सभी readers उपयोग कर सकते हैं, इसलिए इसे TaskDesc::regions documentation string में जोड़ना बेहतर होगा।

• Debugging प्रक्रिया का मूल्यांकन

  • यह जटिल समस्या को debug करने की गहरी analysis देता है, और सिस्टम का बाकी हिस्सा stable बना रहा, यह Oxide टीम की उच्च-गुणवत्ता engineering का प्रमाण है। मुझे इससे व्यक्तिगत रूप से प्रेरणा मिली है और मैं काम पर इसी तरह की techniques अपनाने की योजना बना रहा/रही हूँ।

• Oxide टीम की संस्कृति में रुचि

  • Oxide की engineering team अंदर ही अंदर अलग-थलग नहीं है; इसकी संस्कृति openness, curiosity, और communication को बढ़ावा देती है, जबकि defensiveness, empire-building, और gatekeeping को हतोत्साहित करती है। उन्होंने ऐसी संस्कृति बनाने और बनाए रखने के लिए मेहनत की है, और यह इस बात से दिखता है कि वे उन सीमाओं के पार horizontally organized हैं जिन्हें दूसरी organizations में अलग-अलग teams कहा जाता। मैं यह और जानना चाहूँगा/चाहूँगी कि ऐसी संस्कृति बनाने के पीछे क्या motivation था और इसके specific execution details क्या थे। क्या किसी organization में "openness, curiosity, communication" को बढ़ावा देने के नुकसान भी होते हैं, और क्या ऐसे मामले हैं जहाँ अधिक सख्त hierarchical system चुनना बेहतर हो? लगता है कि org chart को strategic तरीके से तय किया जाना चाहिए, लेकिन उसके trade-offs मुझे अच्छी तरह समझ नहीं आते।

• संबंधित जानकारी का लिंक

  • पृष्ठभूमि की जानकारी दिए गए link के ज़रिए मिल सकती है।

• Debugging के दौरान होने वाली समस्या से सहमति

  • debug code जोड़ते ही गायब हो जाने वाले random crashes सच में सबसे बुरे crashes होते हैं, इस बात से सहमति है।

• Hardware handling पर सुझाव

  • hardware को soft-filled TLB की तरह handle करके 8 से अधिक regions को support किया जा सकता है, यह बात कही गई है।

• Oxide के काम की प्रशंसा

  • Oxide जो काम कर रहा है, उस पर आश्चर्य और प्रशंसा व्यक्त की गई है।

• ऑपरेटिंग सिस्टम के नाम पर प्रतिक्रिया

  • operating system का नाम Hubris रखने पर आश्चर्य और प्रतिक्रिया व्यक्त की गई है।