VPS-এ AES-NI পরীক্ষা ও আবার চালু করার উপায়

VPS-এ AES-NI আসলে কী সুবিধা দেয়

VPS-এ AES-NI হলো ছয়টি x86 instruction-এর একটি সেট, যা hardware-এ AES (advanced encryption standard)-এর একটি round সম্পন্ন করে। আপনার provider-এর CPU model যদি এই instruction-গুলো আড়াল করে, তবুও underlying silicon-এ এগুলো থাকে। কিন্তু OpenSSL এগুলো দেখতে না পারায় software implementation-এ ফিরে যায়, যেখানে প্রতি byte-এ প্রায় দশ গুণ বেশি cycle লাগে। একটি command-এ feature-টি পরীক্ষা করা যায়, দুটি command-এ পার্থক্য মাপা যায়, এবং প্রায়ই একটি environment variable দিয়ে দ্রুত পথটি আবার চালু করা যায়।

Instruction-গুলো হলো AESENC, AESENCLAST, AESDEC, AESDECLAST, AESIMC এবং AESKEYGENASSIST। Intel 2010 সালে এগুলো প্রকাশ করে এবং AMD পরে একই সুবিধা যোগ করে। তাই আপনি যে server CPU ভাড়া নেওয়ার সম্ভাবনা রাখেন, তার silicon-এ এগুলো থাকার কথা। একটি সহায়ক instruction, PCLMULQDQ, carry-less multiplication সম্পন্ন করে। GCM (Galois/counter mode)-এর authentication tag তৈরির জন্য এটি প্রয়োজন। উভয়টি available থাকলেই AES-GCM দ্রুত হয়, কারণ cipher এবং tag তৈরি আলাদা কাজ।

VPS-এ monitoring-এর সময় এই সুবিধা চারটি জায়গায় দেখা যায়:

• TLS (transport layer security) termination। AES-128-GCM বা AES-256-GCM সরবরাহকারী web server bulk cryptography-এর বেশির ভাগ সময় AES-এর ভিতরে ব্যয় করে।
• Encrypted volume। LUKS (Linux unified key setup) এবং dm-crypt kernel-এ, CPU ব্যবহার করে, প্রতিটি read এবং প্রতিটি write-এর সময় aes-xts চালায়।
• AES-ভিত্তিক VPN traffic। AES-256-GCM-সহ OpenVPN এবং AES-GCM-সহ IPsec উভয়ই এর ওপর নির্ভর করে।
• Encrypted backup। কোনো কিছু box থেকে বের হওয়ার আগে AES দিয়ে stream encrypt করলে একই খরচ হয়।

একটি সাধারণ workload এতে একেবারেই প্রভাবিত হয় না। WireGuard তার data-এর জন্য ChaCha20-Poly1305 ব্যবহার করে এবং AES কখনো ব্যবহার করে না। তাই flag masked থাকা host-এও একটি নিজে পরিচালিত WireGuard VPN একই গতিতে চলে। সস্তা VPS-এর জন্য tunnel বেছে নেওয়ার আগে OpenVPN-এর সঙ্গে WireGuard তুলনা করা-র একটি বাস্তব কারণ হলো এই পার্থক্য।

আপনার VPS-এ AES-NI আছে কি না কীভাবে পরীক্ষা করবেন

Kernel CPUID feature bit-গুলো /proc/cpuinfo-এ কপি করে। তাই একটি grep command-ই যথেষ্ট।

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

যেকোনো command-এ aes দেখালে বোঝায়, CPU এই guest-কে AES-NI feature জানাচ্ছে। কিছুই না দেখালে feature-টি নেই। lscpu একই flag পড়ে, তাই দুটি command-এর ফল সবসময় এক হবে। যেটি ইনস্টল করা আছে, সেটি ব্যবহার করুন।

এখন 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-টি pass through করছে। QEMU Virtual CPU version 2.5+ বা Common KVM processor দেখালে অন্য কিছু ঘটছে। এই অবস্থাটিই বোঝা গুরুত্বপূর্ণ।

সিলিকনে সুবিধাটি থাকলেও flag অনুপস্থিত কেন

CPUID হলো এমন একটি instruction, যা কোনো program CPU কোন কোন সুবিধা সমর্থন করে তা জানতে ব্যবহার করে। Virtual machine-এর ভেতরে CPUID সব সময় hypervisor-এ trap করে। তাই guest-কে কী জানানো হবে, তা hypervisor নির্ধারণ করে। অধিকাংশ panel এই সিদ্ধান্তকে guest CPU model হিসেবে প্রকাশ করে। qemu64 এবং kvm64 generic baseline model। এ দুটির feature set-এ AES-NI বা SSSE3 কোনোটিই নেই। তাই physical host-টি বর্তমান EPYC হলেও guest কোনো aes flag দেখতে পায় না। VPS হলো অন্যের hardware-এ চলা guest। তাই এটি যে feature report করে, প্রতিটি feature এক স্তর ওপরে নেওয়া সিদ্ধান্তের ফল। এই layering আপনার কাছে নতুন হলে VPS কী দিয়ে শুরু করুন।

Host ইচ্ছাকৃতভাবে একটি generic model বেছে নেয়। কারণ ভিন্ন processor-যুক্ত machine-এর মধ্যে live migration তখনই কাজ করে, যখন guest-কে এমন কোনো feature সম্পর্কে জানানো হয়নি, যা destination machine-এ নেই। এর খরচ আপনাকেই বহন করতে হয়। আপনার kernel এবং আপনার OpenSSL-এর copy—উভয়ই startup-এর সময় masked CPUID একবার পড়ে। এরপর process চলাকালীন উভয়ই ধীর code path ব্যবহার করে।

মূল সমাধান host-side setting-এ: QEMU-এর ভাষায় -cpu host, AES-NI অন্তর্ভুক্ত এমন একটি named model, অথবা model-এ যোগ করা একটি explicit +aes। Guest-এর ভেতর থেকে এগুলোর কোনোটি set করা যায় না। Support ticket খোলা, অথবা এমন plan বেছে নেওয়া যার hypervisor CPU model pass through করে—এটাই স্থায়ী সমাধান।

openssl speed দিয়ে পার্থক্য পরিমাপ করুন

প্রকাশিত কোনো benchmark যাচাই না করে বিশ্বাস করবেন না। আপনার নিজের server যে cipher ব্যবহার করে, সেটিই চালিয়ে দেখুন।

openssl version
openssl speed -evp aes-128-gcm

ফলাফলের row-টি AES-128-GCM নামে চিহ্নিত থাকে এবং 6টি block size-এ throughput দেখায়; একক হলো প্রতি সেকেন্ডে 1000 bytes। bulk transfer-এর জন্য 8192-byte column দেখুন, কারণ 16-byte column-এ প্রতি call-এর overhead প্রধান হয়ে ওঠে এবং file download সম্পর্কে কোনো কার্যকর তথ্য দেয় না।

এবার software-এ AES-NI এবং PCLMULQDQ বন্ধ রেখে একই command চালান:

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

এই মান OpenSSL-এর নিজস্ব capability vector documentation থেকে এসেছে। শুরুতে ~ থাকলে তার অর্থ হলো “এই bit-গুলো clear করুন”। Bit 57 হলো AES-NI এবং bit 33 হলো PCLMULQDQ। তাই 0x200000200000000 কেবল এই 2টি bit-ই নির্দিষ্ট করে, অন্য কিছু নয়। দ্বিতীয় মানটি প্রথমটির তুলনায় অনেক কম হলে বুঝবেন আপনার machine-এ 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-এর জন্য প্রকাশিত representative figure; কোনো নির্দিষ্ট host থেকে নেওয়া measurement নয়। এগুলোকে একটি সাধারণ চিত্র হিসেবে দেখুন। Hardware path প্রায় 0.7 cycles per byte এবং software fallback প্রায় 11.0 cycles per byte-এ চলে। এক core-এ এর অর্থ প্রায় 4,850 MB/s বনাম 310 MB/s। আপনার উপরের 2টি command-ই আপনার server বর্ণনা করার একমাত্র নির্ভরযোগ্য সংখ্যা দেয়। Machine-এর বাকি অংশের ক্ষেত্রেও একই পদ্ধতি অনুসরণ করুন। তাই কোনো plan সম্পর্কে সিদ্ধান্ত নেওয়ার আগে এটিকে VPS benchmark করার একটি পুনরাবৃত্তিযোগ্য পদ্ধতি-এর সঙ্গে মিলিয়ে দেখুন।

OPENSSL_ia32cap দিয়ে বিটগুলো আবার সক্রিয় করুন

এখানেই বিষয়টি অনেককে অবাক করে। AES-NI নির্দেশনাগুলো unprivileged, এবং hypervisor এগুলো trap করে না। শুধু CPUID trap করা হয়। তাই কোনো host আপনার guest-কে জানাতে পারে যে AES-NI নেই, অথচ AESENC native গতিতে পূর্ণ speed-এ চলতে থাকে। Software CPUID জিজ্ঞাসা করে ভুল উত্তর পাওয়ার কারণে fast path এড়িয়ে যায়। নির্দেশনাটি নিজে কখনো কাজ করা বন্ধ করেনি।

OpenSSL CPU-এর হয়ে উত্তর দেওয়ার সুযোগ দেয়। OPENSSL_ia32cap-তে একটি সাধারণ hexadecimal value দিলে সেটি capability vector mask না করে overwrite করে।

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

এই run যদি plain run-এর চেয়ে কয়েক গুণ দ্রুত হয়, তাহলে silicon-এ AES-NI আছে এবং আপনার host সেটি গোপন করছে। এটি প্রথমে একটি diagnosis। OpenSSL-এর ক্ষেত্রে এটি একই সঙ্গে একটি fix-ও।

এখানে দুটি সতর্কতা প্রযোজ্য, এবং আপনি ইচ্ছা করেই দুটিই ঘটাতে পারেন।

শুধু প্রথম vector সেট করলে পরের vector-গুলো zero থাকে। এতে AVX2 এবং AVX-512 code path বন্ধ হয়ে যায়। এখানে এটি ইচ্ছাকৃত। masked guest-এ AVX bit জোর করে সক্রিয় করার চেষ্টা করবেন না, কারণ AVX register ব্যবহারের জন্য operating system-কে XCR0-এ extended state সক্রিয় করতে হয়, এবং একই masked CPUID-এর ভিত্তিতে আপনার kernel তা করেনি। এরপর একটি VEX-encoded instruction undefined-opcode fault তৈরি করে এবং process বন্ধ হয়ে যায়।

বাস্তবে AES-NI না থাকা কোনো core-এ AES-NI জোর করে সক্রিয় করলে process সঙ্গে সঙ্গে বন্ধ হয়ে যায়:

Illegal instruction (core dumped)

এটি AESENC-এর undefined-opcode fault তৈরি করার ফল, কারণ ওই core-এ চালানোর মতো এমন কোনো instruction নেই। কিছু 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-টির মান আবার দেখাবে। আপনি কী ঝুঁকি গ্রহণ করছেন তা বুঝে নিন: ওই server কখনো এমন host-এ migrate হলে যার CPU-তে সত্যিই AES-NI নেই, nginx-এর প্রথম TLS connection-এই illegal instruction-এর কারণে বন্ধ হয়ে যাবে। এটি আপনার runbook-এ লিখে রাখুন। অথবা override production-এ একেবারেই রাখবেন না; ticket খোলার সময় বিষয়টি প্রমাণ করার জন্য শুধু ব্যবহার করুন।

ওভাররাইড যা ঠিক করে না

OPENSSL_ia32cap OpenSSL-এ পৌঁছায়, অন্য কোথাও নয়। অন্য সব সফটওয়্যার নিজস্ব feature detection চালায় এবং এই variable কখনো পড়ে না।

Kernel-ই গুরুত্বপূর্ণ ক্ষেত্র। dm-crypt এবং LUKS kernel crypto API ব্যবহার করে। CPU feature bit অনুপস্থিত থাকলে aesni_intel module load হতে অস্বীকার করে:

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

এর জন্য user-space variable নেই। Kernel boot-এর সময় একবার CPUID পড়ে। এরপর সেই সিদ্ধান্ত অপরিবর্তিত থাকে, যতক্ষণ না আপনি অন্য host-এ reboot করেন। তাই OpenSSL যা-ই করুক, আপনার encrypted volume software cipher-এই থাকে। আপনি বাস্তবে কী পাচ্ছেন তা মাপুন:

sudo cryptsetup benchmark -c aes-xts -s 256

Hardware AES থাকলে aes-xts 256b row-এর গতি হাজার MiB/s-এ পৌঁছায়। Hardware AES না থাকলে তা কম শত MiB/s-এর মধ্যে থাকে। নিজস্ব detection ব্যবহার করা language runtime-গুলোকেও এভাবে নিয়ন্ত্রণ করা যায় না; Go এবং Java তার উদাহরণ। Go-এর crypto/aes সরাসরি CPUID পরীক্ষা করে। bit clear থাকলে এটি নীরবে constant-time software implementation ব্যবহার করে। আপনার TLS termination service যদি Go binary হয়, OpenSSL variable পরিবর্তন করলে তার কোনো প্রভাব পড়বে না।

AES-NI পাওয়া না গেলে ChaCha20-কে অগ্রাধিকার দিন

ChaCha20-Poly1305 সাধারণ সফটওয়্যারে দ্রুত চলার জন্য তৈরি করা হয়েছে। ব্যবহারযোগ্য AES-NI ছাড়া কোনো core-এ এটি সাধারণত AES-GCM-এর চেয়ে অনেক দ্রুত কাজ করে। তাই এমন host-এ AES-কে অগ্রাধিকার দেওয়া বন্ধ করাই যুক্তিসংগত।

OpenSSL 1.1.1 বা নতুন সংস্করণের বিপরীতে build করা nginx 1.19.4 বা নতুন সংস্করণের জন্য:

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 কভার করে। TLS 1.3-এর জন্য nginx-এ কোনো dedicated directive নেই। এটি string-টি সরাসরি OpenSSL-এ পাঠায় এবং যাচাই করে না। তাই সেখানে বানান ভুল হলেও তা নীরবে গ্রহণ করা হয়। Reload করে client-কে কী দেওয়া হচ্ছে তা নিশ্চিত করুন:

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 host-এ ভিন্ন extension ব্যবহার হয়

AES-NI শুধু x86-এ রয়েছে। ARM VPS-এ ARMv8 cryptographic extension ব্যবহার করা হয়। এটি একই কাজের জন্য আলাদা instruction set। aarch64-এ flag-গুলো flags-এর পরিবর্তে Features-এর অধীনে থাকে:

grep -m1 Features /proc/cpuinfo

aes এবং pmull খুঁজুন। pmull হলো PCLMULQDQ-এর ARM counterpart, এবং একই কারণে GCM-এর জন্য এটি প্রয়োজন। ARM-এ OpenSSL-এর override variable হলো OPENSSL_armcap। এর bit layout OpenSSL source-এর crypto/arm_arch.h-এ সংজ্ঞায়িত করা আছে। তাই এই গাইডের x86 hex value সেখানে কোনো অর্থ বহন করে না। বাস্তবে VPS host হিসেবে ব্যবহৃত ARM server core-গুলোতে সাধারণত এই extension সক্রিয় থাকে। তাই masked-feature সমস্যা মূলত x86-সংক্রান্ত।

ব্যর্থতার ধরন এবং যে স্ট্রিংগুলো আপনি দেখবেন

/proc/cpuinfo-এ aes নেই, এবং জোর করে চালানো রানটি অনেক দ্রুত। হোস্ট CPUID আড়াল করছে। মডেলের নামটি generic কি না নিশ্চিত করুন। এরপর আপনার provider-কে জিজ্ঞাসা করুন, তাদের hypervisor কোন guest CPU model উপস্থাপন করে।

/proc/cpuinfo-এ aes নেই, এবং জোর করে চালানো রানটি Illegal instruction প্রিন্ট করে। নির্দেশনাগুলো সত্যিই অনুপস্থিত, অথবা firmware সেগুলো নিষ্ক্রিয় করেছে। workload-টি অন্য host-এ সরান।

aes উপস্থিত, কিন্তু throughput এখনও কম। আপনি 8192-byte column পড়ছেন কি না নিশ্চিত করুন এবং core-টি অন্য কোনো process ব্যবহার করছে কি না পরীক্ষা করুন। shared plan-এ noisy neighbour-এর কারণে CPU feature অনুপস্থিত বলে মনে হতে পারে, যতক্ষণ না দিনের ভিন্ন সময়ে test-টি দুবার চালান।

masked run এবং normal run একই number দেয়। OpenSSL ইতিমধ্যে software path ব্যবহার করছিল। এটিই পরীক্ষার ফলাফল; test-এ কোনো ভুল হয়নি।

Nested virtualisation এক স্তর নিচে ফলাফল পরিবর্তন করে। একটি guest-এর ভেতরের guest মধ্যবর্তী layer যে CPUID pass করার সিদ্ধান্ত নিয়েছে, সেটিই পায়। সেখানে AES-NI সহজেই অজান্তে হারিয়ে যেতে পারে। আপনি যদি একটি VPS-এ nested virtual machines চালান, তাহলে ভাড়া নেওয়া machine-এ এবং inner guest-এর ভেতরেও flag পরীক্ষা করুন।

FAQ

আমার VPS-এ /proc/cpuinfo-তে aes flag নেই কেন?

কারণ hypervisor একটি generic guest CPU model উপস্থাপন করছে। qemu64 এবং kvm64-এর feature set-এ AES-NI নেই, তাই physical processor যা-ই হোক, CPUID এটিকে অনুপস্থিত হিসেবে জানায়। ভিন্ন CPU-যুক্ত মেশিনের মধ্যে চলমান guest migrate করা যায় তা নিশ্চিত করতে host-গুলো এমন করে। 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 enable করে, নাকি শুধু ভান করে?

এটি প্রকৃত instruction enable করে। AES-NI instruction unprivileged, এবং hypervisor কখনো এগুলো trap করে না। তাই CPUID যা-ই জানাক, AESENC native-ভাবে execute হয়। শুধু CPUID instruction intercept করা হয়। OPENSSL_ia32cap-এ সাধারণ hexadecimal value সেট করলে OpenSSL, CPUID থেকে পাওয়া উত্তরটি প্রতিস্থাপন করে। ফলে OpenSSL hardware code path নির্বাচন করে এবং hardware সেটি পূর্ণ গতিতে চালায়। Silicon-এ সত্যিই instruction না থাকলে প্রথম AES operation-এর সময় process Illegal instruction (core dumped) দিয়ে বন্ধ হয়ে যায়।

এই override কি আমার LUKS encrypted volume-এর গতি বাড়াবে?

না। OPENSSL_ia32cap শুধু OpenSSL পড়ে; অন্য কোনো software এটি পড়ে না। LUKS এবং dm-crypt kernel crypto API ব্যবহার করে। Feature bit clear থাকলে সেখানে 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 দিয়ে প্রকৃত ফলাফল মাপুন এবং aes-xts 256b row-টি এমন একটি host-এর সঙ্গে তুলনা করুন, যেখানে flag-টি রিপোর্ট করা হয়।

AES-NI flag না থাকলে কি WireGuard ধীর হয়ে যায়?

না। WireGuard সব data-এর জন্য ChaCha20-Poly1305 ব্যবহার করে এবং কখনো AES instruction ব্যবহার করে না। তাই masked host এবং unmasked host-এ এর throughput একই থাকে। AES-GCM দিয়ে configured OpenVPN এবং IPsec, AES-NI-বিহীন host-এ throughput হারায়। ফলে একই VPS-এর দুটি tunnel-এর আচরণ অনেক ভিন্ন হতে পারে। Network-কে দোষ দেওয়ার আগে এটি জানা দরকার।

ARM VPS-এ AES-NI আছে কি না কীভাবে পরীক্ষা করব?

ARM core-এ AES-NI থাকে না। এগুলোতে ARMv8 cryptographic extension থাকে, যা ভিন্ন instruction ব্যবহার করে একই কাজ করে। grep -m1 Features /proc/cpuinfo চালিয়ে aes এবং pmull খুঁজুন। aarch64 এগুলো Features-এর অধীনে তালিকাভুক্ত করে, flags-এর অধীনে নয়। x86-এর OPENSSL_ia32cap value ARM-এ অর্থহীন। সেখানে OpenSSL-এর সমতুল্য variable হলো OPENSSL_armcap। এর bit layout OpenSSL source-এর crypto/arm_arch.h-এ সংজ্ঞায়িত আছে।