OpenSSL मधील AES-NI की कर्नेल ऑफलोड: तुम्हाला कोणते हवे?

दोन लेबल एकाच गोष्टीसारखे वापरले जातात: हार्डवेअर-त्वरित आणि कर्नेलमध्ये हलवलेले. एक सांगते की लायब्ररीची AES रुटीन कोणत्या सूचना चालवते, आणि दुसरे सांगते की पॅकेट प्रक्रिया कुठे होते. VPN कडे पहिले दुसऱ्याशिवाय, दुसरे पहिल्याशिवाय, किंवा दोन्ही एकत्र असू शकतात. कार्यक्षमतेबद्दलचा कोणताही निर्णय तुम्ही या दोनपैकी कोणते खरोखर बदलत आहात हे नाव देण्यापासून सुरू झाला पाहिजे.

दोन अक्ष, एक गुण नाही

पहिला अक्ष अंमलबजावणी आहे: AES-256-GCM करणारा कोड प्रोसेसरच्या समर्पित सूचना वापरणाऱ्या आवृत्तीकडे जातो की त्यांना सामान्य अंकगणित म्हणून चालवणाऱ्या पोर्टेबल रुटीनकडे. ही निवड क्रिप्टोग्राफिक लायब्ररीच्या आत राहते आणि ती सुरू होताना केली जाते.

दुसरा अक्ष स्थान आहे: पॅकेट कर्नेलच्या रूपांतरण मार्गाने जाते की वापरकर्ता जागेतील डेमन टनेल उपकरणातून वाचते, एन्क्रिप्ट करते आणि परत लिहिते.

कोणताही अक्ष दुसऱ्याला मर्यादित करत नाही. AES सूचना असलेल्या CPU वर वापरकर्ता जागेतील VPN त्या सतत वापरू शकते, आणि त्या नसलेल्या CPU वर कर्नेल मार्ग सॉफ्टवेअर अंमलबजावणीकडे परत जातो. विक्रेत्यांच्या साहित्यातील लेबल हा फरक क्वचितच दाखवतात, म्हणूनच दोन परिस्थितींमध्ये नकल केलेला ट्यूनिंग सल्ला इतक्या वेळा काहीच करत नाही.

अक्ष एक: कोणता कोड एन्क्रिप्शन करतो

OpenSSL सुरुवातीला प्रोसेसरची वैशिष्ट्ये शोधते आणि सुधारित कोड मार्ग निवडण्यासाठी निकाल वापरते, जसे x86 क्षमतांचे दस्तऐवज वर्णन करते. AES-NI त्या वळणामागील नोंदवलेल्या क्षमतांपैकी एक आहे. यापैकी काहीही लायब्ररी कर्नेल घटक होण्याची मागणी करत नाही.

वेगवान मार्ग वापरला जातो असे गृहीत धरण्यापूर्वी वैशिष्ट्य प्रक्रियेला दिसते याची खात्री करा. Linux वर स्रोत /proc/cpuinfo मधील flags फील्ड आहे, आणि गेस्टमध्ये ते हायपरवायझर जे उघड करतो ते प्रतिबिंबित करते, भौतिक होस्टचे मॉडेल नाव नाही.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

दुसरा कमांड त्या बिल्डमध्ये लोड केलेल्या पुरवठादारांची नावे सांगतो. तो तुम्हाला सांगत नाही की VPN सेवेने कोणती लायब्ररी जोडली, आणि एका होस्टवर दोन OpenSSL इन्स्टॉलेशन असू शकतात तर चालू प्रक्रिया त्यातील एकच वापरते.

अक्ष दोन: पॅकेट मार्ग कुठे चालतो

कर्नेलमध्ये ठेवणे म्हणजे रूपांतरण कर्नेलच्या स्वतःच्या IPsec यंत्रणेत किंवा कर्नेलमधील टनेल ड्रायव्हरमध्ये होते, त्यामुळे पॅकेट्सना प्रत्येक बॅचसाठी वापरकर्ता जागेतील प्रक्रियेतून ये-जा करावी लागत नाही. यामुळे प्रत आणि संदर्भ बदल कमी होऊ शकतात, आणि एका थ्रेडच्या डेमनला जमणार नाही अशा पद्धतीने काम कोअर्सवर पसरू शकते. हे ते काउंटर आणि ट्रेस देखील हलवते जे तुम्ही थ्रूपुट घटल्यावर वाचाल, कारण काम आता तुमच्या नियंत्रणाबाहेरच्या सीमेच्या पलीकडे होते. हे केवळ कार्यक्षमतेचा निर्णय नाही तर डीबगिंगचा खर्च माना.

ते सूचना समर्थन तयार करत नाही, सायफर कॉन्फिगर करत नाही आणि असलेला मार्ग चालू करत नाही.

व्हर्च्युअलायझेशन या अक्षावरही एक घडी घालते. गेस्टला होस्टकडे असलेली वैशिष्ट्ये लपवणारे मास्क केलेले CPU मॉडेल दिले जाऊ शकते, आणि आतमध्ये असलेल्या गेस्टला अजून कमी दिसू शकते. क्षमतांचे दृश्य VPN प्रत्यक्षात चालत असलेल्या वातावरणाच्या आतून वाचा, हायपरवायझर कन्सोलमधून नाही.

प्रत्येक निवड काय विकत घेते, आणि काय करू शकत नाही

व्यावहारिक प्रश्न असा आहे की वेळ कुठे जातो. जर एक व्यस्त थ्रेड, वारंवार बफर प्रत किंवा प्रत्येक पॅकेटला सिस्टम कॉल थ्रूपुट मर्यादित करत असेल, तर ते खर्च दूर करणाऱ्या मार्गावर रूपांतरण हलवणे मदत करू शकते, जर कर्नेलने आवश्यक रूपांतरण अंमलात आणले असेल.

जर मर्यादा गर्दीची वरची लिंक, तोट्याचा मार्ग, लांब ये-जा वेळ, भरलेली गंतव्य सेवा किंवा एका कोअरला खिळलेला एक थ्रेड असेल, तर स्थान काही महत्त्वाचे बदलत नाही. सूचना निवडीलाही तेच लागू: समर्पित हार्डवेअरवरील AES गमावलेला मार्ग दुरुस्त करू शकत नाही आणि नाव विश्लेषण अयशस्वी झाल्याने टनेल रिकामे असेल तर मदत करणार नाही.

दोन्ही लागू होतात तिथे ते एकत्र येतात. कर्नेल मार्ग कर्नेलच्या क्रिप्टो API मधील तेच सूचना-स्तरीय वळण वापरू शकतो, आणि चांगल्या निवडलेल्या लायब्ररीसह वापरकर्ता जागेचा मार्ग ते आधीच वापरत आहे. निर्णय कोणते अमूर्तपणे वेगवान हा नाही; कोणत्या खर्चासाठी तुमच्याकडे पुरावा आहे हा आहे.

काहीही बदलण्यापूर्वी चार तथ्ये लिहा

सेवेची बाइनरी आणि ती जोडलेली क्रिप्टो लायब्ररी लिहा, कारण तीच अक्ष एक ठरवतात. नंतर ठरलेले डेटा संरक्षण नोंदवा, कारण समर्पित सूचना मार्ग नसलेला सायफर त्याच्यासह असलेल्यापेक्षा वेगळा वागतो, आणि संच दोन्ही बाजू निवडतात.

त्यानंतर, चालू वातावरणाच्या आतून क्षमतांचे दृश्य, आणि शेवटी सक्रिय पॅकेट मार्गासह पुरावा की तुम्ही सक्षम मानत असलेला मोड खरोखर तसाच आहे. लोड केलेला मॉड्यूल प्रोफाइल तो वापरते याचा पुरावा नाही, आणि कॉन्फिगरेशन ओळ कर्नेलने ती स्वीकारली याचा पुरावा नाही.

एक गोष्ट बदला, नंतर तेच टोक आणि तीच हस्तांतरण दिशा असलेल्या सुसंगत कामाच्या भाराशी तुलना करा. तुम्ही मोजली नाही अशी गतीची दावा बॅकएंड कधीच शंकेत नव्हता अशा टिपेपेक्षा कमी मूल्याचा आहे.