सर्वर की हिंस्रता का चयन

Hubris IPC का अवलोकन

• Hubris एक छोटे, application-independent kernel का उपयोग करता है, और अधिकांश code (driver, application logic, network stack आदि) अलग से compile किए गए isolated tasks में मौजूद होता है
• ये tasks cross-task messaging system (IPC) का उपयोग करके एक-दूसरे से communicate कर सकते हैं
• Hubris का IPC kernel में implement किए गए 3 मुख्य operations (RECV, SEND, REPLY) से बना है
  • RECV: आने वाले सबसे उच्च-प्राथमिकता वाले message को collect करता है, या message आने तक block करता है
  • SEND: message और control को receiving task को transfer करता है और caller को रोक देता है। caller response मिलने तक waiting state में चला जाता है
  • REPLY: पहले SEND का उपयोग करने वाले task को response देता है ताकि वह आगे बढ़ सके

नए और दिलचस्प failure modes

• क्योंकि IPC task boundaries को पार करता है और Hubris के tasks अलग से compile किए गए programs हैं, इसलिए IPC में वैसी ही assumptions करते समय सावधानी ज़रूरी है जैसी compiler function calls के समय मानकर चलता है
• Hubris में IPC server की भूमिका निभाने वाले सभी tasks को निम्न संभावित errors संभालने होते हैं:
  • interface और operation code के मेल न खाने वाले messages प्राप्त होना
  • अपेक्षित message type के बजाय ऐसे bytes का समूह मिलना जिसे parse नहीं किया जा सके, या बहुत छोटा या बहुत बड़ा message मिलना
  • आवश्यक memory (जैसे writable memory) प्राप्त न होना

सामान्य और सही programs में ये स्थितियाँ नहीं होतीं

• सामान्य Hubris programs में ऊपर बताई गई स्थितियाँ नहीं होतीं
• tasks build system की configuration के ज़रिए एक-दूसरे से जुड़े होते हैं, इसलिए उनका आपस में भ्रमित होना कठिन है
• client और server generated Rust code का उपयोग करते हैं, इसलिए यह मान सकते हैं कि type system task boundaries के पार भी काम कर रही है

kernel किसी भी बकवास को बर्दाश्त नहीं करता

• Unix में system call की preconditions का उल्लंघन करने पर caller को error code लौटाया जाता है, लेकिन Hubris में task तुरंत नष्ट कर दिया जाता है
• Hubris kernel Synthetic Fault नामक अवधारणा के माध्यम से kernel rules का उल्लंघन करने वाले tasks को fault पहुँचाता है
• Hubris में hardware या synthetic fault होने पर task तुरंत रुक जाता है और उससे recovery संभव नहीं होती

server भी किसी भी बकवास को बर्दाश्त नहीं करता

• REPLY_FAULT नाम की 13वीं और सबसे असामान्य system call के माध्यम से server client को fault पहुँचा सकता है
• REPLY_FAULT, REPLY जैसा है, लेकिन message देकर task को runnable state में लाने के बजाय fault देता है और task को रोक देता है
• REPLY_FAULT के माध्यम से अनावश्यक IPC error handling से बचा जा सकता है। सामान्य programs ऐसे काम करते हैं मानो समस्या हो ही नहीं सकती, और असामान्य programs को error handle करने का मौका भी नहीं मिलता
• REPLY_FAULT application-specific faults, जैसे access control rules, को परिभाषित और implement करने का नया तरीका देता है

GN⁺ की राय

• REPLY_FAULT एक शक्तिशाली mechanism है जो server को client side के सहयोग के बिना भी client में cross-process panic! ट्रिगर करने देता है। इससे Hubris malicious programs के प्रति बेहद शत्रुतापूर्ण system बन जाता है
• REPLY_FAULT की कमी यह है कि fuzzing test बहुत कठिन हो जाते हैं। random IPC या system calls बनाने वाला chaos engineering task लगभग हर व्यवहार में तुरंत reset हो जाता है
• लेकिन सामान्य Hubris tasks dynamically IPC messages generate नहीं करते, इसलिए वे REPLY_FAULT के अस्तित्व को जाने बिना भी काम कर सकते हैं
• REPLY_FAULT के ज़रिए server client में मनमाने faults पैदा कर सकता है, लेकिन इसका मूल्यांकन अभी पूरी तरह नहीं हुआ है
• Hubris की आक्रामक error handling development के शुरुआती चरण में bugs खोजने में मदद करती है, और error codes के विपरीत errors को अनदेखा करना असंभव बना देती है
• IPC errors को संभालने का सार्वभौमिक तरीका अपनाने से सामान्य programs पर भी अनावश्यक overhead आ सकता है। REPLY_FAULT इससे बचते हुए असामान्य programs के प्रति सख्ती बनाए रखने वाला एक elegant solution लगता है

[GN⁺]

Hacker News राय

संक्षेप में, मुख्य बातें इस प्रकार हैं:

• REPLY_FAULT के chain की तरह propagate होने की संभावना और उससे पैदा होने वाली vulnerability को लेकर चिंता जताई गई

  • A अगर B का इंतज़ार कर रहा हो, और B, C का इंतज़ार कर रहा हो, तो C के REPLY_FAULT करने पर क्या A भी साथ में terminate हो जाएगा, यह जाँचने की ज़रूरत है
  • अगर ऐसा है, तो पूरा system कमज़ोर हो सकता है
  • अगर SEND circular structure में हो, तो अनजाने में system खुद को ही terminate कर सकता है

• REPLY_FAULT access control जैसी application-specific errors को define और implement करने का तरीका देता है

  • यह तब उपयोगी है जब system छोटा, tightly coupled हो, और ज़्यादातर application system designer ही लिख रहा हो
  • लेकिन third-party code के साथ integration में यह चिंता रहती है कि सामने वाला कभी भी process को तुरंत terminate कर सकता है
  • दुनिया में ऐसे बहुत से खराब driver और background process मौजूद हैं जिन्हें managers के दबाव में काम कर रहे developers ने लिखा है

• ऐसे system में जहाँ एक ही team सारा code लिखती है, संदिग्ध clients को हटा देना iteration speed बढ़ा सकता है

• Hubris को ऐसे kernel की तरह देखा जा सकता है जो server को ऐसे effects करने देता है जिन्हें client handle नहीं कर सकता

  • इससे code reuse और composition मुश्किल हो जाते हैं, लेकिन execution model सरल हो जाता है
  • static embedded systems में यह सही trade-off हो सकता है

• Hubris और Humility ऐसी technologies हैं जिनमें गहराई से डूबकर काम करने का मन होता है, लेकिन समय और ज़िम्मेदारियों की सीमाएँ बाधा बनती हैं

• HTTP पर एक April Fools RFC में HTTP 499 status code प्रस्तावित किया गया, जिसका मतलब है "तुम्हें शर्म आनी चाहिए"

  • यह "क्या... लेकिन सच कहें तो ठीक ही है" जैसे संदर्भ में फिट बैठता है

• Einstein के कथन "यथासंभव सरल बनाओ, लेकिन उससे ज़्यादा सरल नहीं" का हवाला देते हुए कहा गया कि Hubris का design दूसरी गलती करता है

  • ऐसे operating environment में कोई रुचि नहीं है जो वास्तविक दुनिया की अव्यवस्था को बिल्कुल भी जगह नहीं देता

• Humility debugger के लिए एक शानदार नाम है

  • कई programmers मान लेते हैं कि "अच्छे" code को debugging की ज़रूरत नहीं होती और इसलिए debugger के इस्तेमाल से बचते हैं

• Linux में केवल sockets के ज़रिए किसी दूसरे program को सीधे terminate नहीं किया जा सकता, लेकिन root privilege होने पर दूसरे process को मारा जा सकता है, यहाँ तक कि reboot भी किया जा सकता है

  • containers में root privilege आम बात है, इसलिए ऐसा जोखिम मौजूद रहता है

• यह "receive करते समय उदार रहो और send करते समय सख्त" जैसी पारंपरिक network wisdom से कुछ हद तक टकराता है

  • लेकिन API बदलते समय पुराने programs के साथ compatibility बनाए रखनी हो, तो receive करते समय उदार रहना लगभग अनिवार्य हो जाता है