इंटेल एसजीएक्स थ्रेडिंग और बनाम टीसीएस

Question

मैं टीसीएस द्वारा सक्षम एसजीएक्स धागे और SDK द्वारा प्रदान किए गए अविश्वसनीय थ्रेडिंग के बीच अंतर को समझने की कोशिश कर रहा हूं।

यदि मैं सही ढंग से समझता हूं, तो टीसीएस एक ही एन्क्लेव में प्रवेश करने के लिए कई लॉजिकल प्रोसेसर सक्षम बनाता है। प्रत्येक लॉजिकल प्रोसेसर का अपना टीसीएस होगा और इसलिए इसका अपना एंट्री पॉइंट होगा (टीसीएस में OENTRY फ़ील्ड)। प्रत्येक धागा तब तक चलता है जब तक एएक्स होता है या धागे के अंत तक पहुंच जाता है। हालांकि, टीसीएस द्वारा सक्षम इन थ्रेडों का अभी तक एक-दूसरे के साथ सिंक्रनाइज़ करने का कोई तरीका नहीं है। कम से कम, सिंक्रनाइज़ करने के लिए कोई एसजीएक्स निर्देश नहीं है।

फिर, दूसरी ओर, एसजीएक्स एसडीके थ्रेड सिंक्रनाइज़ेशन प्राइमेटिव्स, मुख्य रूप से म्यूटेक्स और कंडीशन वैरिएबल का एक सेट प्रदान करता है। ये प्राइमेटिव्स विश्वसनीय नहीं हैं क्योंकि अंततः उन्हें ओएस द्वारा परोसा जाता है।

मेरा प्रश्न है, क्या ये थ्रेड सिंक्रनाइज़ेशन Primitives का उपयोग टीसीएस धागे द्वारा किया जाना था? यदि हां, तो क्या इससे सुरक्षा खराब हो जाएगी? ओएस शेड्यूलिंग के साथ खेलना चाहता है क्योंकि यह चाहती है।

Answer 1

पहले, हमें

SGX धागे टीसीएस और एसडीके द्वारा प्रदान की अविश्वस्त सूत्रण से सक्षम के अपने कुछ हद तक स्पष्ट नहीं शब्दावली के साथ सौदा करते हैं।

एक संलग्नक के अंदर, केवल "विश्वसनीय" थ्रेड निष्पादित हो सकते हैं। एक संलग्नक के अंदर कोई "अविश्वसनीय" थ्रेडिंग नहीं है। संभवतः, एसडीके गाइड में निम्नलिखित वाक्य [1] ने आपको गुमराह किया:

एनक्लेव के अंदर धागे बनाना समर्थित नहीं है। धागे कि एन्क्लेव के अंदर चलाने (अविश्वस्त) आवेदन के भीतर बनाई गई हैं।

अविश्वसनीय एप्लिकेशन को टीसीएस पृष्ठों को स्थापित करना होगा (टीसीएस पर अधिक पृष्ठभूमि के लिए देखें [2])। तो अविश्वसनीय आवेदन द्वारा स्थापित टीसीएस कैसे संलग्नक के अंदर विश्वसनीय धागे की नींव हो सकता है? [2] उत्तर देता है:

ईईंटर केवल सभी संलग्न टीसीएस पृष्ठों की सामग्री को मापने पर एन्क्लेव कोड के अंदर नियंत्रित कूद को करने की गारंटी है।

टीसीएस पृष्ठों को मापकर, धागे की अखंडता (टीसीएस अनुमत प्रवेश बिंदु परिभाषित करता है) संलग्नक सत्यापन के माध्यम से सत्यापित किया जा सकता है। तो केवल ज्ञात-अच्छा निष्पादन पथ संलग्नक के भीतर निष्पादित किया जा सकता है।

दूसरा, आइए हम सिंक्रनाइज़ेशन प्राइमेटिव देखें।

एसडीके सिंक्रनाइज़ेशन प्राइमेटिव्स प्रदान करता है, जो आप कहते हैं कि भरोसा नहीं किया जाना चाहिए क्योंकि उन्हें अंततः ओएस द्वारा परोसा जाता है। में [1] इन पुरातन का वर्णन पर देखने की सुविधा देता है:

• sgx_spin_lock() और केवल एन्क्लेव (परमाणु संचालन का प्रयोग करके) के भीतर काम, ओएस बातचीत (कोई OCALL) की कोई आवश्यकता के साथ अनलॉक। एक स्पिनलॉक का उपयोग करके, आप स्वयं उच्च स्तरीय प्राइमेटिव लागू कर सकते हैं।
• sgx_thread_mutex_init() भी ओकॉल नहीं बनाता है। Mutex डेटा संरचना enclave के भीतर शुरू किया गया है।
• sgx_thread_mutex_lock() और संभवतः ओकल्स को अनलॉक करें। हालांकि, चूंकि म्यूटेक्स डेटा एन्क्लेव के भीतर है, इसलिए वे हमेशा सुरक्षित एनक्लेव के भीतर लॉकिंग की शुद्धता को लागू कर सकते हैं।

म्यूटेक्स फ़ंक्शंस के विवरणों को देखते हुए, मेरा अनुमान है कि ओकॉल एनक्लेव के बाहर गैर-व्यस्त प्रतीक्षा को लागू करने के लिए काम करता है। यह वास्तव में ओएस द्वारा संभाला जाता है, और हमलों के लिए अतिसंवेदनशील है। ओएस एनक्लेव के बाहर इंतजार कर रहे थ्रेड को नहीं उठाने का विकल्प चुन सकता है। लेकिन यह एक संलग्नक के अंदर चल रहे थ्रेड को बाधित करने का भी चयन कर सकता है। एसजीएक्स (संभावित रूप से समझौता) ओएस से डीओएस हमलों (सेवा अस्वीकार) के खिलाफ सुरक्षा नहीं करता है।

सारांशित करने के लिए, स्पिन-लॉक (और विस्तार से किसी उच्च-स्तरीय सिंक्रनाइज़ेशन) को एक संलग्नक के अंदर सुरक्षित रूप से कार्यान्वित किया जा सकता है। हालांकि, एसजीएक्स डीओएस हमलों के खिलाफ सुरक्षा नहीं करता है, और इसके लिए आप यह नहीं मान सकते कि धागा चल जाएगा। यह प्राइमेटिव लॉक करने पर भी लागू होता है: म्यूटेक्स को मुक्त होने पर एक म्यूटेक्स पर प्रतीक्षा करने वाला धागा जागृत नहीं हो सकता है। इस अंतर्निहित सीमा को समझते हुए, एसडीके डिजाइनरों ने कुछ सिंक्रनाइज़ेशन प्राइमेटिव्स (यानी गैर-व्यस्त प्रतीक्षा) को कुशलतापूर्वक कार्यान्वित करने के लिए (अविश्वसनीय) ओकॉल का उपयोग करना चुना।

[1] SGX SDK Guide

[2] SGX Explained

Answer 2

qweruiop, टिप्पणी में अपने प्रश्न के बारे में (मेरा उत्तर बहुत लंबा एक टिप्पणी के लिए है):

मैं अभी भी है कि एक माना जाएगा डीओएस हमला: ओएस, जो enclaves के संसाधनों का प्रबंधन करता है, संसाधन सीपीयू प्रोसेसिंग समय संसाधन के लिए टी पहुंच से इनकार करता है। लेकिन मैं मानता हूं, आपको उस एनक्लेव में चल रहे अन्य थ्रेडों को जागरूकता के साथ डिजाइन करना होगा जो टी कभी नहीं चल सकता है। अर्थात् आपके द्वारा नियंत्रित प्लेटफ़ॉर्म पर थ्रेड चलाने से अलग होते हैं। यदि आप पूरी तरह से यह सुनिश्चित करना चाहते हैं कि कंडीशन वैरिएबल चेक किया गया है, तो आपको उस प्लेटफॉर्म पर ऐसा करना होगा जिसे आप नियंत्रित करते हैं।

sgx_status_t प्रत्येक प्रॉक्सी फ़ंक्शन द्वारा लौटाया गया है (उदाहरण के लिए जब एक एन्क्लेव में ईसीएल बनाते हैं) SGX_ERROR_OUT_OF_TCS लौटा सकता है। तो एसडीके को आपके लिए सभी थ्रेडिंग को संभालना चाहिए - केवल ईसीएल को दो अलग-अलग ("अविश्वसनीय") थ्रेड ए और बी से संलग्न करें, और निष्पादन प्रवाह को संलग्नक के अंदर दो ("विश्वसनीय") धागे में जारी रखना चाहिए, प्रत्येक बाध्य एक अलग टीसीएस (माना जाता है कि 2 अप्रयुक्त टीसीएस उपलब्ध हैं)।