VPS पर AES-NI कैसे चेक करें और इसे इनेबल करें

VPS पर AES-NI वास्तव में आपको क्या लाभ देता है

VPS पर AES-NI छह x86 निर्देशों का एक समूह है जो हार्डवेयर में AES (एडवांस्ड एन्क्रिप्शन स्टैंडर्ड) का एक राउंड पूरा करता है। यदि आपके प्रोवाइडर का CPU मॉडल इन्हें छिपाता है, तो भी अंतर्निहित सिलिकॉन में ये मौजूद होते हैं, लेकिन OpenSSL इन्हें देख नहीं पाता और सॉफ्टवेयर इम्प्लीमेंटेशन का उपयोग करने लगता है, जिसमें प्रति बाइट लगभग दस गुना अधिक साइकिल खर्च होती है। आप एक कमांड से इस फीचर की जाँच कर सकते हैं, दो कमांड से अंतर माप सकते हैं, और अक्सर एक एनवायरनमेंट वेरिएबल के साथ फास्ट पाथ को वापस सक्रिय कर सकते हैं।

ये निर्देश AESENC, AESENCLAST, AESDEC, AESDECLAST, AESIMC और AESKEYGENASSIST हैं। Intel ने इन्हें 2010 में पेश किया था और AMD ने भी इसका अनुसरण किया, इसलिए आप जो भी सर्वर CPU किराए पर लेंगे, उसमें यह सिलिकॉन मौजूद होने की संभावना है। एक सहयोगी निर्देश, PCLMULQDQ, कैरी-लेस मल्टीप्लिकेशन करता है, जिसकी आवश्यकता GCM (गैलोइस/काउंटर मोड) को अपना ऑथेंटिकेशन टैग बनाने के लिए होती है। AES-GCM तभी तेज होता है जब ये दोनों उपलब्ध हों, क्योंकि सिफर और टैग अलग-अलग कार्य हैं।

VPS पर चार स्थान जहाँ यह आपकी मॉनिटरिंग में दिखाई देता है:

• TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) टर्मिनेशन। AES-128-GCM या AES-256-GCM का उपयोग करने वाला वेब सर्वर अपना अधिकांश बल्क-क्रिप्टो समय AES के भीतर व्यतीत करता है।
• एन्क्रिप्टेड वॉल्यूम। LUKS (लिनक्स यूनिफाइड की सेटअप) और dm-crypt हर रीड और हर राइट पर, कर्नल में, CPU पर aes-xts चलाते हैं।
• AES-आधारित VPN ट्रैफिक। AES-256-GCM के साथ OpenVPN और AES-GCM के साथ IPsec, दोनों ही इस पर निर्भर हैं।
• एन्क्रिप्टेड बैकअप। कोई भी प्रक्रिया जो बॉक्स से बाहर जाने से पहले AES के साथ स्ट्रीम को एन्क्रिप्ट करती है, उसे समान लागत चुकानी पड़ती है।

एक सामान्य वर्कलोड बिल्कुल भी प्रभावित नहीं होता है। WireGuard अपने डेटा के लिए ChaCha20-Poly1305 का उपयोग करता है और कभी भी AES को टच नहीं करता है, इसलिए एक self-hosted WireGuard VPN उस होस्ट पर भी समान गति से चलता है जहाँ फ्लैग मास्क्ड (छिपा हुआ) हो। यह अंतर एक सस्ता VPS चुनने से पहले WireGuard और OpenVPN की तुलना करने का एक व्यावहारिक कारण है।

यह कैसे जाँचें कि आपके VPS में AES-NI है या नहीं

Kernel CPUID feature bits को /proc/cpuinfo में कॉपी करता है, इसलिए एक grep कमांड से ही उत्तर मिल जाता है।

grep -m1 -o '\baes\b' /proc/cpuinfo
lscpu | grep -i -o '\baes\b'

यदि कोई भी कमांड aes प्रिंट करती है, तो इसका अर्थ है कि CPU इस guest को AES-NI की सुविधा देता है। यदि कुछ भी प्रिंट नहीं होता है, तो इसका अर्थ है कि यह सुविधा उपलब्ध नहीं है। lscpu भी उन्हीं flags को पढ़ता है, इसलिए दोनों का परिणाम हमेशा एक समान होता है। जो भी कमांड उपलब्ध हो, उसका उपयोग करें।

अब देखें कि host के अनुसार आप कौन सा CPU चला रहे हैं।

grep -m1 'model name' /proc/cpuinfo

Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz या AMD EPYC 7443P 24-Core Processor जैसी वास्तविक model string का अर्थ है कि host आपको physical CPU model की जानकारी दे रहा है। QEMU Virtual CPU version 2.5+ या Common KVM processor का अर्थ है कि कुछ और हो रहा है, और उस स्थिति को समझना आवश्यक है।

जब सिलिकॉन में फ्लैग मौजूद है, तो वह गायब क्यों है

CPUID वह instruction है जिसका उपयोग कोई प्रोग्राम यह पूछने के लिए करता है कि CPU किन सुविधाओं का समर्थन करता है। वर्चुअल मशीन के अंदर, CPUID हमेशा हाइपरवाइजर (hypervisor) तक जाता है, इसलिए हाइपरवाइजर ही यह तय करता है कि गेस्ट को क्या बताया जाए। अधिकांश पैनल उस निर्णय को गेस्ट CPU मॉडल के रूप में प्रदर्शित करते हैं। qemu64 और kvm64 सामान्य बेसलाइन मॉडल हैं, और इनमें से कोई भी अपने फीचर सेट में AES-NI या SSSE3 को शामिल नहीं करता है, इसलिए गेस्ट को कोई aes फ्लैग नहीं दिखता, भले ही फिजिकल होस्ट एक आधुनिक EPYC प्रोसेसर हो। VPS किसी और के हार्डवेयर पर एक गेस्ट होता है, इसलिए यह जो भी फीचर रिपोर्ट करता है, वह एक स्तर ऊपर लिया गया निर्णय होता है। यदि यह लेयरिंग आपके लिए नई है, तो VPS क्या है से शुरुआत करें।

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

इसका समाधान सोर्स स्तर पर एक होस्ट-साइड सेटिंग है: QEMU के संदर्भ में -cpu host, एक ऐसा नामित मॉडल जिसमें AES-NI शामिल हो, या मॉडल में स्पष्ट रूप से जोड़ा गया +aes। आप इनमें से कुछ भी गेस्ट के अंदर से सेट नहीं कर सकते। सपोर्ट टिकट खोलना, या ऐसा प्लान चुनना जिसका हाइपरवाइजर CPU मॉडल को सीधे पास (pass-through) करता हो, इसका स्थायी समाधान है।

openssl speed के साथ अंतर को मापें

प्रकाशित बेंचमार्क पर आँख बंद करके भरोसा न करें। वह cipher चलाएं जिसे आपका सर्वर वास्तव में negotiate करता है।

openssl version
openssl speed -evp aes-128-gcm

परिणाम पंक्ति को AES-128-GCM लेबल दिया गया है और यह 1000 bytes प्रति सेकंड की इकाइयों में छह block sizes पर throughput प्रदान करती है। bulk transfer के लिए 8192-byte वाला column देखें, क्योंकि 16-byte वाला column per-call overhead से प्रभावित होता है और file download के बारे में कोई जानकारी नहीं देता है।

अब AES-NI और PCLMULQDQ को software में बंद करके वही command चलाएं:

OPENSSL_ia32cap="~0x200000200000000" openssl speed -evp aes-128-gcm

वह मान OpenSSL के अपने capability vector documentation से आता है। एक अग्रणी ~ का अर्थ है "इन bits को clear करें"। Bit 57 AES-NI है और bit 33 PCLMULQDQ है, इसलिए 0x200000200000000 ठीक उन्हीं दो को नाम देता है और कुछ नहीं। यदि दूसरी संख्या पहली से काफी कम है, तो इसका मतलब है कि आपके box में AES-NI काम कर रहा है और आपका काम पूरा हो गया है। यदि दोनों संख्याएं मेल खाती हैं, तो इसका मतलब है कि OpenSSL पहले से ही software path पर था, क्योंकि clear करने के लिए वह flag वहां मौजूद ही नहीं था।

[
  {
    "label": "AES-NI and PCLMULQDQ",
    "mb_per_sec": "4,850",
    "cycles_per_byte": 0.7
  },
  {
    "label": "Software fallback",
    "mb_per_sec": 310,
    "cycles_per_byte": 11.0
  }
]

ये 3.4 GHz के करीब एक आधुनिक x86 core के लिए प्रतिनिधि प्रकाशित आंकड़े हैं, न कि किसी एक host से लिया गया माप। इन्हें एक आकार के रूप में पढ़ें। hardware path लगभग 0.7 cycles प्रति byte पर चलता है और software fallback लगभग 11.0 पर, जो एक core पर 310 MB/s के मुकाबले लगभग 4,850 MB/s बैठता है। ऊपर दी गई आपकी दो commands ही वह एकमात्र संख्या उत्पन्न करती हैं जो आपके सर्वर का वर्णन करती है। यही अनुशासन मशीन के बाकी हिस्सों पर भी लागू होता है, इसलिए किसी योजना के बारे में निष्कर्ष निकालने से पहले इसे VPS को बेंचमार्क करने का एक दोहराने योग्य तरीका के साथ जोड़ें।

OPENSSL_ia32cap के साथ बिट्स को जबरन चालू करना

यह वह हिस्सा है जो लोगों को हैरान करता है। AES-NI निर्देश unprivileged होते हैं और hypervisor उन्हें trap नहीं करता है। केवल CPUID को trap किया जाता है। इसलिए, एक host आपके guest को यह बता सकता है कि AES-NI अनुपस्थित है, जबकि AESENC पूरी गति से natively निष्पादित होता रहता है। सॉफ्टवेयर fast path को छोड़ देता है क्योंकि उसने CPUID से पूछा और उसे गलत उत्तर मिला। निर्देश ने स्वयं काम करना कभी बंद नहीं किया था।

OpenSSL आपको CPU की ओर से उत्तर देने की अनुमति देता है। OPENSSL_ia32cap में एक साधारण hexadecimal मान capability vector को mask करने के बजाय उसे overwrite कर देता है।

OPENSSL_ia32cap="0x0200020207000000" openssl speed -evp aes-128-gcm

यदि वह run साधारण run की तुलना में कई गुना तेज है, तो silicon में AES-NI मौजूद है और आपका host इसे छिपा रहा है। यह सबसे पहले एक निदान (diagnosis) है। OpenSSL के लिए, यह एक समाधान भी है।

दो चेतावनियाँ लागू होती हैं, और आप जानबूझकर दोनों को trigger कर सकते हैं।

केवल पहले vector को set करने से बाद के vectors शून्य पर रह जाते हैं, जो AVX2 और AVX-512 code paths को बंद कर देता है। यहाँ यह जानबूझकर किया गया है। masked guest पर AVX bits को जबरन चालू करने का प्रयास न करें, क्योंकि AVX registers को extended state को XCR0 में सक्षम करने के लिए operating system की आवश्यकता होती है, और आपके kernel ने उसी masked CPUID के आधार पर ऐसा करने से इनकार कर दिया था। एक VEX-encoded निर्देश तब एक undefined-opcode fault उत्पन्न करता है और process समाप्त हो जाती है।

ऐसे core पर AES-NI को जबरन चालू करना जिसमें वास्तव में इसकी कमी है, process को तुरंत समाप्त कर देता है:

Illegal instruction (core dumped)

यह AESENC है जो एक undefined-opcode fault उत्पन्न कर रहा है, क्योंकि उस core पर निष्पादित करने के लिए ऐसा कोई निर्देश नहीं है। कुछ server firmware भी अगले reset तक hardware में AES-NI को अक्षम कर सकते हैं, और लक्षण बिल्कुल समान होते हैं। किसी भी स्थिति में, समाधान एक अलग host है, न कि कोई अलग environment variable।

लंबे समय तक चलने वाली service के लिए override को बनाए रखने के लिए, एक systemd drop-in का उपयोग करें।

sudo systemctl edit nginx

[Service]
Environment="OPENSSL_ia32cap=0x0200020207000000"

sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemctl show nginx -p Environment

अंतिम command को variable को वापस आपके पास print करना चाहिए। समझें कि आप किस चीज के लिए सहमति दे रहे हैं: यदि उस server को कभी ऐसे host पर migrate किया जाता है जिसके CPU में वास्तव में AES-NI की कमी है, तो nginx अपने पहले TLS connection पर illegal instruction के साथ समाप्त हो जाएगा। इसे अपनी runbook में डालें, या override को production से पूरी तरह बाहर रखें और इसका उपयोग केवल तब करें जब आप ticket खोलते समय अपनी बात सिद्ध करना चाहते हों।

ओवरराइड जो समस्या हल नहीं करता है

OPENSSL_ia32cap केवल OpenSSL तक पहुँचता है और किसी अन्य चीज़ पर नहीं। अन्य सभी सॉफ़्टवेयर अपना स्वयं का फ़ीचर डिटेक्शन चलाते हैं और उस वेरिएबल को कभी नहीं पढ़ते हैं।

कर्नेल एक महत्वपूर्ण मामला है। dm-crypt और LUKS कर्नेल क्रिप्टो API का उपयोग करते हैं, और जब CPU फ़ीचर बिट गायब होता है तो aesni_intel मॉड्यूल लोड होने से मना कर देता है:

modprobe: ERROR: could not insert 'aesni_intel': No such device

इसके लिए कोई user-space वेरिएबल नहीं है। कर्नेल बूट के समय एक बार CPUID पढ़ता है और वह निर्णय तब तक बना रहता है जब तक आप किसी अलग होस्ट पर रीबूट नहीं करते, इसलिए OpenSSL चाहे जो भी करे, आपका एन्क्रिप्टेड वॉल्यूम सॉफ़्टवेयर साइफर पर ही रहता है। मापें कि आपको वास्तव में क्या मिल रहा है:

sudo cryptsetup benchmark -c aes-xts -s 256

aes-xts 256b पंक्ति हार्डवेयर AES के साथ हजारों MiB/s में और उसके बिना कुछ सौ MiB/s में आती है। Go और Java सहित अपने स्वयं के डिटेक्शन वाले लैंग्वेज रनटाइम भी इसी तरह पहुंच से बाहर हैं। Go का crypto/aes सीधे CPUID की जाँच करता है और बिट क्लियर होने पर चुपचाप अपने कॉन्स्टेंट-टाइम सॉफ़्टवेयर कार्यान्वयन का उपयोग करता है। यदि आपके TLS को समाप्त करने वाली सर्विस एक Go बाइनरी है, तो OpenSSL वेरिएबल इसके लिए कुछ भी नहीं बदलता है।

यदि आपको AES-NI उपलब्ध नहीं है, तो ChaCha20 को प्राथमिकता दें

ChaCha20-Poly1305 को विशेष रूप से सॉफ्टवेयर में तेज गति से काम करने के लिए डिज़ाइन किया गया था। जिस core में AES-NI का उपयोग नहीं किया जा सकता, वहां यह आमतौर पर AES-GCM से काफी बेहतर प्रदर्शन करता है। इसलिए, ऐसे host पर AES को प्राथमिकता न देना ही समझदारी है।

nginx 1.19.4 और उसके बाद के संस्करणों के लिए, जिन्हें OpenSSL 1.1.1 या उसके बाद के संस्करण के साथ build किया गया है:

ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384;

ssl_ciphers TLS 1.2 को कवर करता है। ssl_conf_command Ciphersuites TLS 1.3 को कवर करता है, जहाँ nginx के पास कोई समर्पित directive नहीं है और यह बिना जाँच किए string को सीधे OpenSSL को भेज देता है, इसलिए वहाँ कोई भी typo चुपचाप स्वीकार कर लिया जाता है। Reload करें और पुष्टि करें कि client को क्या offer किया जा रहा है:

sudo nginx -t && sudo systemctl reload nginx
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep -i cipher

एक सही परिणाम में TLS_CHACHA20_POLY1305_SHA256 का नाम दिखाई देगा। बदलाव को लागू करने से पहले, उसी box पर AES run के साथ openssl speed -evp chacha20-poly1305 चलाएँ और इन दो संख्याओं के आधार पर निर्णय लें।

ARM hosts अलग extensions का उपयोग करते हैं

AES-NI केवल x86 के लिए है। एक ARM VPS, ARMv8 cryptographic extensions का उपयोग करता है, जो एक अलग instruction set है और वही कार्य करता है। aarch64 पर flags Features के अंतर्गत होते हैं, न कि flags के:

grep -m1 Features /proc/cpuinfo

aes और pmull को खोजें। pmull, PCLMULQDQ का ARM समकक्ष है, और GCM को उसी कारण से इसकी आवश्यकता होती है। ARM पर OpenSSL का override variable OPENSSL_armcap है, जिसका अपना bit layout OpenSSL source में crypto/arm_arch.h में परिभाषित है, इसलिए इस guide में दिया गया x86 hex मान वहाँ कोई अर्थ नहीं रखता। व्यवहार में, VPS hosts के रूप में बेचे जाने वाले ARM server cores इन extensions को expose करते हैं, इसलिए masked-feature की समस्या मुख्य रूप से x86 तक ही सीमित है।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

aes का /proc/cpuinfo में न होना और forced run का बहुत तेज होना। होस्ट CPUID को मास्क कर रहा है। पुष्टि करें कि मॉडल का नाम जेनेरिक है, फिर अपने प्रदाता से पूछें कि उनका हाइपरवाइजर कौन सा guest CPU मॉडल प्रस्तुत करता है।

aes का /proc/cpuinfo में न होना और forced run का Illegal instruction प्रिंट करना। निर्देश वास्तव में अनुपस्थित हैं, या फर्मवेयर ने उन्हें अक्षम कर दिया है। वर्कलोड को किसी दूसरे होस्ट पर ले जाएं।

aes मौजूद है लेकिन थ्रूपुट अभी भी कम है। जांचें कि आप 8192-byte कॉलम पढ़ रहे हैं, और कोर का उपयोग कोई अन्य प्रक्रिया नहीं कर रही है। साझा प्लान (shared plan) पर, एक 'noisy neighbour' तब तक गायब CPU फीचर जैसा दिखता है जब तक आप दिन के अलग-अलग समय पर टेस्ट को दो बार न चला लें।

masked run और normal run एक ही परिणाम देते हैं। OpenSSL पहले से ही सॉफ्टवेयर पाथ पर था। वह परिणाम ही निष्कर्ष है, टेस्ट में कोई गलती नहीं है।

Nested virtualisation एक स्तर नीचे उत्तर बदल देती है। एक guest के अंदर मौजूद guest को वही CPUID मिलता है जिसे बीच की परत (middle layer) ने पास करने के लिए चुना है, और वहां AES-NI का पता चले बिना खो जाना आसान है। यदि आप VPS पर nested virtual machines चलाते हैं, तो inner guest के अंदर और आपके द्वारा किराए पर ली गई मशीन दोनों पर फ्लैग की जांच करें।

FAQ

मेरे VPS में /proc/cpuinfo में aes flag क्यों नहीं है?

इसका कारण यह है कि hypervisor एक सामान्य guest CPU model प्रस्तुत कर रहा है। qemu64 और kvm64 अपने feature sets में AES-NI को शामिल नहीं करते हैं, इसलिए CPUID इसे अनुपस्थित बताता है, चाहे भौतिक प्रोसेसर कोई भी हो। hosts ऐसा इसलिए करते हैं ताकि चलते हुए guest को अलग-अलग CPU वाले मशीनों के बीच migrate किया जा सके। grep -m1 'model name' /proc/cpuinfo चलाएँ: QEMU Virtual CPU version 2.5+ या Common KVM processor जैसी string यह संकेत देती है, जबकि एक वास्तविक Xeon या EPYC model string का मतलब है कि CPU model को pass-through किया गया है और flag वास्तव में silicon में मौजूद नहीं है।

क्या OPENSSL_ia32cap वास्तव में AES-NI को सक्षम करता है, या यह केवल दिखावा है?

यह वास्तविक निर्देशों (instructions) को सक्षम करता है। AES-NI निर्देश unprivileged होते हैं और hypervisor उन्हें कभी trap नहीं करता है, इसलिए AESENC CPUID की रिपोर्ट के बावजूद natively निष्पादित होता है। केवल CPUID निर्देश को ही intercept किया जाता है। OPENSSL_ia32cap को एक plain hexadecimal मान पर सेट करने से वह उत्तर बदल जाता है जो OpenSSL को CPUID से मिला था, इसलिए OpenSSL अपने hardware code path का चयन करता है और hardware फिर उसे पूरी गति से चलाता है। यदि silicon में वास्तव में निर्देश नहीं हैं, तो प्रक्रिया पहले AES operation पर Illegal instruction (core dumped) के साथ समाप्त हो जाएगी।

क्या यह override मेरे LUKS encrypted volume की गति बढ़ाएगा?

नहीं। OPENSSL_ia32cap को केवल OpenSSL पढ़ता है, कोई और नहीं। LUKS और dm-crypt kernel crypto API का उपयोग करते हैं, जहाँ feature bit स्पष्ट न होने पर aesni_intel module modprobe: ERROR: could not insert 'aesni_intel': No such device के साथ load होने में विफल रहता है। kernel boot के समय CPUID पढ़ता है और कोई भी user-space variable इसे नहीं बदल सकता। sudo cryptsetup benchmark -c aes-xts -s 256 के साथ वास्तविक आंकड़े मापें और उस host के मुकाबले aes-xts 256b row की तुलना करें जो flag की रिपोर्ट करता है।

क्या AES-NI flag न होने से WireGuard धीमा हो जाता है?

नहीं। WireGuard सभी डेटा के लिए ChaCha20-Poly1305 का उपयोग करता है और कभी भी AES निर्देशों का उपयोग नहीं करता है, इसलिए masked और unmasked host दोनों पर इसकी throughput समान रहती है। AES-GCM के साथ कॉन्फ़िगर किए गए OpenVPN और IPsec की throughput AES-NI के बिना host पर निश्चित रूप से कम हो जाती है। इसलिए एक ही VPS पर दो tunnels का व्यवहार बहुत अलग हो सकता है, जिसे नेटवर्क को दोष देने से पहले जानना आवश्यक है।

मैं ARM VPS पर AES-NI की जाँच कैसे करूँ?

ARM cores में AES-NI नहीं होता है। उनमें ARMv8 cryptographic extensions होते हैं, जो अलग निर्देशों के साथ वही काम करते हैं। grep -m1 Features /proc/cpuinfo चलाएँ और aes तथा pmull को खोजें, क्योंकि aarch64 इन्हें flags के बजाय Features के अंतर्गत सूचीबद्ध करता है। x86 OPENSSL_ia32cap मान का ARM पर कोई अर्थ नहीं है। वहाँ OpenSSL का समकक्ष variable OPENSSL_armcap है, और इसका bit layout OpenSSL source में crypto/arm_arch.h में परिभाषित है।