بررسی و فعال‌سازی AES-NI در VPS با OpenSSL

مزایای واقعی AES-NI روی یک VPS

قابلیت AES-NI روی یک VPS مجموعه‌ای از 6 دستورالعمل x86 است که یک دور از AES (استاندارد رمزنگاری پیشرفته) را در سطح سخت‌افزار انجام می‌دهد. اگر مدل CPU ارائه‌دهندهٔ شما این دستورالعمل‌ها را مخفی کند، سیلیکون زیرین همچنان آن‌ها را دارد، اما OpenSSL نمی‌تواند آن‌ها را ببیند و به پیاده‌سازی نرم‌افزاری بازمی‌گردد که تقریباً 10 برابر بیشتر در هر بایت، چرخهٔ پردازشی مصرف می‌کند. شما می‌توانید این ویژگی را با یک دستور بررسی کنید، شکاف عملکردی را با دو دستور اندازه بگیرید و اغلب با یک متغیر محیطی، مسیر سریع را دوباره فعال کنید.

این دستورالعمل‌ها عبارتند از AESENC، AESENCLAST، AESDEC، AESDECLAST، AESIMC و AESKEYGENASSIST. اینتل آن‌ها را در سال 2010 عرضه کرد و AMD نیز از آن پیروی کرد، بنابراین هر CPU سروری که احتمالاً اجاره می‌کنید، این سیلیکون را دارد. یک دستورالعمل مکمل به نام PCLMULQDQ، ضرب بدون انتقال (carry-less multiplication) را انجام می‌دهد که همان چیزی است که GCM (حالت گالوا/شمارنده) برای ساخت تگ احراز هویت خود به آن نیاز دارد. AES-GCM تنها زمانی سریع است که هر دو در دسترس باشند، زیرا رمزنگاری و تگ، دو بخش مجزا از کار هستند.

چهار بخش در یک VPS که این موضوع در مانیتورینگ شما نمایان می‌شود:

• پایان‌دهی TLS (امنیت لایه انتقال). یک وب‌سرور که AES-128-GCM یا AES-256-GCM ارائه می‌دهد، بیشتر زمان رمزنگاری حجیم خود را صرف AES می‌کند.
• درایوهای رمزنگاری‌شده. LUKS (تنظیم کلید یکپارچه لینوکس) و dm-crypt دستور aes-xts را در هر خواندن و نوشتن، در سطح هسته و روی CPU اجرا می‌کنند.
• ترافیک VPN مبتنی بر AES. هم OpenVPN با AES-256-GCM و هم IPsec با AES-GCM به آن متکی هستند.
• بک‌آپ‌های رمزنگاری‌شده. هر چیزی که یک جریان داده را قبل از خروج از سرور با AES رمزنگاری کند، همین هزینه را می‌پردازد.

یک بار کاری رایج اصلاً تحت تأثیر قرار نمی‌گیرد. WireGuard برای داده‌های خود از ChaCha20-Poly1305 استفاده می‌کند و هرگز به AES دست نمی‌زند، بنابراین یک VPN مبتنی بر WireGuard که خودتان میزبانی می‌کنید، روی میزبانی که این پرچم در آن مخفی شده باشد، با همان سرعت اجرا می‌شود. این تفاوت یک دلیل عملی برای سنجش WireGuard در برابر OpenVPN پیش از انتخاب تونل برای یک VPS ارزان‌قیمت است.

نحوه بررسی پشتیبانی VPS از AES-NI

هسته سیستم‌عامل بیت‌های ویژگی CPUID را در /proc/cpuinfo کپی می‌کند، بنابراین با یک دستور grep می‌توان به این پرسش پاسخ داد.

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

اگر هر یک از این دو دستور عبارت aes را چاپ کنند، به این معناست که CPU قابلیت AES-NI را به این guest معرفی کرده است. اگر خروجی خالی باشد، یعنی این قابلیت وجود ندارد. دستور 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 به این معناست که میزبان، مدل فیزیکی CPU را مستقیماً به شما منتقل می‌کند. خروجی QEMU Virtual CPU version 2.5+ یا Common KVM processor به این معناست که وضعیت متفاوتی در جریان است و این همان موردی است که ارزش بررسی و درک را دارد.

چرا با وجود پشتیبانی سخت‌افزار، پرچم (flag) مربوطه دیده نمی‌شود

CPUID دستوری است که برنامه از طریق آن از CPU می‌پرسد چه قابلیت‌هایی را پشتیبانی می‌کند. در یک ماشین مجازی، دستور CPUID همیشه به هایپروایزر (hypervisor) ارجاع داده می‌شود، بنابراین هایپروایزر تصمیم می‌گیرد که چه اطلاعاتی به سیستم‌عامل مهمان (guest) داده شود. اکثر پنل‌های مدیریتی این تصمیم را در قالب مدل CPU مهمان ارائه می‌دهند. qemu64 و kvm64 مدل‌های پایه و عمومی هستند و هیچ‌کدام شامل AES-NI یا SSSE3 در مجموعه قابلیت‌های خود نیستند؛ به همین دلیل، مهمان حتی زمانی که میزبان فیزیکی یک EPYC مدرن باشد، هیچ پرچم aes را مشاهده نمی‌کند. یک VPS در واقع مهمانِ سخت‌افزار شخص دیگری است، بنابراین هر قابلیتی که گزارش می‌دهد، تصمیمی است که یک لایه بالاتر گرفته شده است. اگر این لایه‌بندی برای شما تازگی دارد، با مفهوم VPS چیست شروع کنید.

میزبان‌ها عمداً یک مدل عمومی را انتخاب می‌کنند، زیرا مهاجرت زنده (live migration) بین ماشین‌هایی با پردازنده‌های متفاوت تنها در صورتی کار می‌کند که به مهمان درباره قابلیتی که مقصد فاقد آن است، چیزی گفته نشده باشد. هزینه این کار بر عهده شماست. هسته سیستم‌عامل و نسخه OpenSSL شما هر دو آن CPUID ماسک‌شده را یک‌بار در زمان شروع به کار می‌خوانند و سپس برای تمام طول عمر آن پردازش، مسیر کد کندتر را انتخاب می‌کنند.

راه‌حل در منبع، یک تنظیم در سمت میزبان است: در اصطلاح QEMU، این تنظیم -cpu host نام دارد؛ یک مدل نام‌گذاری‌شده که شامل AES-NI باشد، یا یک +aes صریح که به مدل اضافه شده باشد. شما نمی‌توانید هیچ‌کدام از این موارد را از داخل مهمان تنظیم کنید. باز کردن تیکت پشتیبانی یا انتخاب طرحی که هایپروایزر آن مدل CPU را مستقیماً عبور می‌دهد (pass-through)، پاسخ قطعی برای این مشکل است.

اندازه‌گیری شکاف با openssl speed

به بنچمارک‌های منتشرشده اعتماد نکنید. الگوریتم رمزنگاری (cipher) که سرور شما واقعاً از آن استفاده می‌کند را تست کنید.

openssl version
openssl speed -evp aes-128-gcm

ردیف نتیجه با برچسب AES-128-GCM مشخص شده و نرخ انتقال داده را در شش اندازه بلوک مختلف، بر حسب 1000 بایت در ثانیه نشان می‌دهد. برای انتقال‌های حجیم، ستون 8192 بایتی را بخوانید؛ چرا که ستون 16 بایتی تحت تأثیر سربار فراخوانی (per-call overhead) قرار دارد و اطلاعاتی درباره دانلود فایل به شما نمی‌دهد.

اکنون همان دستور را با غیرفعال کردن AES-NI و PCLMULQDQ در نرم‌افزار اجرا کنید:

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

این مقدار از مستندات بردار قابلیت‌های (capability vector) خود OpenSSL به دست آمده است. علامت ~ در ابتدای عبارت به معنای «پاک کردن این بیت‌ها» است. بیت 57 مربوط به AES-NI و بیت 33 مربوط به PCLMULQDQ است، بنابراین 0x200000200000000 دقیقاً همین دو مورد را هدف قرار می‌دهد. اگر عدد دوم بسیار کمتر از عدد اول باشد، یعنی سرور شما از AES-NI فعال برخوردار است و کار تمام است. اگر دو عدد با هم برابر باشند، یعنی OpenSSL از قبل در مسیر نرم‌افزاری بوده است، زیرا آن پرچم (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
  }
]

این‌ها ارقام منتشرشده و نمونه برای یک هسته مدرن x86 با فرکانس نزدیک به 3.4 GHz هستند و اندازه‌گیری از یک میزبان خاص نیستند. آن‌ها را به عنوان یک الگو در نظر بگیرید. مسیر سخت‌افزاری تقریباً با 0.7 سیکل به ازای هر بایت و مسیر جایگزین نرم‌افزاری با تقریباً 11.0 سیکل اجرا می‌شود که معادل حدود 4,850 مگابایت بر ثانیه در مقابل 310 مگابایت بر ثانیه روی یک هسته است. دو دستوری که در بالا اجرا کردید، تنها اعدادی هستند که وضعیت سرور شما را توصیف می‌کنند. همین نظم و انضباط برای سایر بخش‌های ماشین نیز صادق است، بنابراین پیش از نتیجه‌گیری درباره یک طرح، این مورد را با یک روش تکرارپذیر برای بنچمارک VPS ترکیب کنید.

بازگرداندن بیت‌ها با استفاده از OPENSSL_ia32cap

این بخشی است که افراد را غافلگیر می‌کند. دستورالعمل‌های AES-NI بدون امتیاز (unprivileged) هستند و هایپروایزر آن‌ها را رهگیری (trap) نمی‌کند. تنها CPUID است که رهگیری می‌شود. بنابراین میزبان (host) می‌تواند به مهمان (guest) بگوید که AES-NI وجود ندارد، در حالی که AESENC همچنان با سرعت کامل به صورت بومی اجرا می‌شود. نرم‌افزار مسیر سریع را نادیده می‌گیرد زیرا از CPUID پرسیده و پاسخ اشتباه دریافت کرده است. خود دستورالعمل هرگز از کار نیفتاده است.

OpenSSL به شما اجازه می‌دهد از طرف CPU پاسخ دهید. یک مقدار هگزادسیمال ساده در OPENSSL_ia32cap، بردار قابلیت‌ها را بازنویسی می‌کند و به جای ماسک کردن، آن را جایگزین می‌کند.

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

اگر آن اجرا چندین برابر سریع‌تر از اجرای معمولی باشد، سیلیکون دارای AES-NI است و میزبان شما آن را پنهان می‌کند. این در درجه اول یک تشخیص است. برای OpenSSL، این اتفاقاً یک راه حل نیز محسوب می‌شود.

دو هشدار وجود دارد که می‌توانید هر دو را عمداً فعال کنید.

تنظیم کردن تنها بردار اول، بردارهای بعدی را صفر باقی می‌گذارد که باعث غیرفعال شدن مسیرهای کد AVX2 و AVX-512 می‌شود. این کار در اینجا عمدی است. سعی نکنید بیت‌های AVX را روی یک مهمان ماسک‌شده فعال کنید، زیرا ثبات‌های AVX نیاز دارند که سیستم‌عامل وضعیت توسعه‌یافته را در XCR0 فعال کند و هسته (kernel) شما بر اساس همان CPUID ماسک‌شده از انجام این کار خودداری کرده است. در این صورت، یک دستورالعمل با کد VEX باعث بروز خطای undefined-opcode شده و پردازش متوقف می‌شود.

اجبار به استفاده از AES-NI روی هسته‌ای که واقعاً فاقد آن است، پردازش را بلافاصله از بین می‌برد:

Illegal instruction (core dumped)

این AESENC است که باعث بروز خطای undefined-opcode می‌شود، زیرا روی آن هسته چنین دستورالعملی برای اجرا وجود ندارد. برخی از فریم‌ورهای سرور نیز می‌توانند AES-NI را در سطح سخت‌افزار تا ریست بعدی غیرفعال کنند و نشانه آن دقیقاً مشابه است. در هر صورت، راه حل، تغییر میزبان است، نه تغییر متغیر محیطی.

برای حفظ این بازنویسی (override) برای یک سرویس طولانی‌مدت، از یک drop-in در systemd استفاده کنید.

sudo systemctl edit nginx

[Service]
Environment="OPENSSL_ia32cap=0x0200020207000000"

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

دستور آخر باید متغیر را به شما بازگرداند. بدانید که چه کاری انجام می‌دهید: اگر آن سرور به میزبانی منتقل شود که CPU آن واقعاً فاقد AES-NI است، nginx در اولین اتصال TLS با خطای illegal instruction متوقف می‌شود. این مورد را در runbook خود ثبت کنید، یا این بازنویسی را کاملاً از محیط production دور نگه دارید و فقط برای اثبات موضوع هنگام باز کردن تیکت پشتیبانی از آن استفاده کنید.

آنچه با این جایگزینی (override) اصلاح نمی‌شود

OPENSSL_ia32cap تنها به OpenSSL می‌رسد و بس. سایر نرم‌افزارها هر کدام قابلیت تشخیص ویژگی‌های خود را دارند و هرگز این متغیر را نمی‌خوانند.

هسته (kernel) مورد مهمی است. dm-crypt و LUKS از API رمزنگاری هسته استفاده می‌کنند و ماژول aesni_intel زمانی که بیت ویژگی CPU موجود نباشد، از بارگذاری خودداری می‌کند:

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 باقی می‌ماند. محیط‌های اجرای زبان (Language runtimes) که تشخیص اختصاصی خود را دارند، از جمله Go و Java، نیز به همین ترتیب خارج از دسترس هستند. دستور crypto/aes در Go مستقیماً CPUID را بررسی می‌کند و در صورت عدم وجود بیت مذکور، بی‌سروصدا از پیاده‌سازی نرم‌افزاری با زمان ثابت (constant-time) خود استفاده می‌کند. اگر سرویسی که TLS شما را terminate می‌کند یک باینری Go باشد، متغیر OpenSSL هیچ تغییری در آن ایجاد نمی‌کند.

اگر به AES-NI دسترسی ندارید، ChaCha20 را ترجیح دهید

الگوریتم ChaCha20-Poly1305 برای عملکرد سریع در محیط‌های نرم‌افزاری طراحی شده است. در پردازنده‌ای که از AES-NI پشتیبانی نمی‌کند، این الگوریتم معمولاً با اختلاف قابل‌توجهی از AES-GCM سریع‌تر عمل می‌کند؛ بنابراین اقدام منطقی در چنین میزبانی، اولویت ندادن به AES است.

برای nginx نسخه 1.19.4 و جدیدتر که با OpenSSL 1.1.1 یا جدیدتر کامپایل شده است:

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 دستورالعمل اختصاصی ندارد و رشته را مستقیماً و بدون بررسی به OpenSSL ارسال می‌کند؛ بنابراین هرگونه غلط تایپی در آن بدون خطا پذیرفته می‌شود. تنظیمات را Reload کنید و بررسی کنید که چه چیزی به کلاینت ارائه می‌شود:

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 است. پیش از نهایی کردن تغییرات، openssl speed -evp chacha20-poly1305 را در کنار اجرای AES روی همان سیستم اجرا کنید و اجازه دهید اعداد، تصمیم نهایی را برای شما بگیرند.

میزبان‌های ARM از افزونه‌های متفاوتی استفاده می‌کنند

قابلیت AES-NI مختص معماری x86 است. یک VPS مبتنی بر ARM از افزونه‌های رمزنگاری ARMv8 استفاده می‌کند که مجموعه‌دستورالعمل مجزایی برای انجام همان وظیفه است. در معماری aarch64، فلگ‌ها به‌جای flags در Features قرار دارند:

grep -m1 Features /proc/cpuinfo

به دنبال aes و pmull بگردید. pmull معادل ARM برای PCLMULQDQ است و GCM به همان دلیل به آن نیاز دارد. متغیر override در OpenSSL برای معماری ARM برابر با OPENSSL_armcap است که طرح‌بندی بیت‌های خاص خود را دارد و در crypto/arm_arch.h در سورس‌کد OpenSSL تعریف شده است؛ بنابراین مقدار هگز x86 در این راهنما، در آنجا کاربردی ندارد. در عمل، هسته‌های سرور ARM که به‌عنوان میزبان VPS فروخته می‌شوند، این افزونه‌ها را در دسترس قرار می‌دهند؛ بنابراین مشکل masked-feature عمدتاً مربوط به معماری x86 است.

حالت‌های شکست و پیام‌هایی که مشاهده خواهید کرد

عدم وجود aes در /proc/cpuinfo، و اجرای اجباری بسیار سریع‌تر است. میزبان در حال ماسک کردن CPUID است. تأیید کنید که نام مدل عمومی است، سپس از ارائه‌دهنده خود بپرسید که هایپروایزر آن‌ها چه مدل CPUای را به مهمان ارائه می‌دهد.

عدم وجود aes در /proc/cpuinfo، و اجرای اجباری عبارت Illegal instruction را چاپ می‌کند. دستورالعمل‌ها واقعاً وجود ندارند یا فریم‌ور آن‌ها را غیرفعال کرده است. بار کاری را به یک میزبان دیگر منتقل کنید.

aes موجود است اما توان عملیاتی همچنان پایین است. بررسی کنید که ستون 8192 بایتی را می‌خوانید و هیچ چیز دیگری از هسته استفاده نمی‌کند. در یک طرح اشتراکی، یک همسایه پرمصرف دقیقاً مانند یک ویژگی CPU گمشده به نظر می‌رسد تا زمانی که تست را دو بار در زمان‌های مختلف روز اجرا کنید.

اجرای ماسک‌شده و اجرای عادی عدد یکسانی را می‌دهند. OpenSSL از قبل در مسیر نرم‌افزاری بوده است. آن نتیجه، یافته نهایی است، نه اشتباه در تست.

مجازی‌سازی تو در تو (Nested virtualisation) پاسخ را یک سطح پایین‌تر تغییر می‌دهد. یک مهمان در داخل یک مهمان دیگر، هر CPUIDای را که لایه میانی برای عبور انتخاب کرده باشد دریافت می‌کند و از دست دادن AES-NI در آنجا بدون متوجه شدن، آسان است. اگر ماشین‌های مجازی تو در تو روی یک VPS را اجرا می‌کنید، پرچم را هم در داخل مهمان داخلی و هم روی ماشینی که اجاره کرده‌اید بررسی کنید.

FAQ

چرا VPS من فاقد فلگ aes در فایل /proc/cpuinfo است؟

زیرا هایپروایزر (hypervisor) یک مدل CPU عمومی را به سیستم‌عامل مهمان معرفی می‌کند. qemu64 و kvm64 شامل AES-NI در مجموعه ویژگی‌های خود نیستند، بنابراین CPUID صرف‌نظر از اینکه پردازنده فیزیکی چیست، آن را غایب گزارش می‌کند. میزبان‌ها این کار را انجام می‌دهند تا امکان انتقال (migration) ماشین مهمان در حال اجرا بین سرورهایی با CPUهای متفاوت فراهم باشد. دستور grep -m1 'model name' /proc/cpuinfo را اجرا کنید: رشته‌ای مانند QEMU Virtual CPU version 2.5+ یا Common KVM processor نشان‌دهنده مجازی‌سازی است، در حالی که مشاهده نام واقعی مدل Xeon یا EPYC به این معناست که مدل CPU مستقیماً عبور داده شده (passthrough) و این فلگ واقعاً در سخت‌افزار وجود ندارد.

آیا OPENSSL_ia32cap واقعاً AES-NI را فعال می‌کند یا فقط آن را شبیه‌سازی می‌کند؟

این متغیر دستورات واقعی را فعال می‌کند. دستورات AES-NI بدون نیاز به سطح دسترسی ویژه (unprivileged) هستند و هایپروایزر هرگز آن‌ها را trap نمی‌کند، بنابراین AESENC فارغ از آنچه CPUID گزارش می‌دهد، به صورت بومی (natively) اجرا می‌شود. تنها دستور CPUID است که توسط هایپروایزر رهگیری می‌شود. تنظیم OPENSSL_ia32cap روی یک مقدار هگزادسیمال ساده، جایگزین پاسخی می‌شود که OpenSSL از CPUID دریافت کرده است؛ در نتیجه OpenSSL مسیر کد سخت‌افزاری خود را انتخاب کرده و سخت‌افزار آن را با سرعت کامل اجرا می‌کند. اگر سخت‌افزار واقعاً فاقد این دستورات باشد، پردازش در اولین عملیات AES با خطای Illegal instruction (core dumped) متوقف می‌شود.

آیا این جایگزینی (override) سرعت پارتیشن رمزنگاری‌شده با LUKS را افزایش می‌دهد؟

خیر. OPENSSL_ia32cap فقط توسط OpenSSL خوانده می‌شود و هیچ تأثیر دیگری ندارد. LUKS و dm-crypt از API رمزنگاری هسته (kernel crypto API) استفاده می‌کنند، جایی که ماژول aesni_intel در صورت نبود بیت ویژگی، با خطای modprobe: ERROR: could not insert 'aesni_intel': No such device بارگذاری نمی‌شود. هسته در زمان بوت، CPUID را می‌خواند و هیچ متغیر فضای کاربری (user-space) نمی‌تواند آن را تغییر دهد. عملکرد واقعی را با sudo cryptsetup benchmark -c aes-xts -s 256 اندازه‌گیری کنید و ردیف aes-xts 256b را با میزبانی که این فلگ را گزارش می‌کند، مقایسه نمایید.

آیا نبود فلگ AES-NI سرعت WireGuard را کاهش می‌دهد؟

خیر. WireGuard برای تمام داده‌ها از ChaCha20-Poly1305 استفاده می‌کند و هرگز از دستورات AES بهره نمی‌برد، بنابراین نرخ انتقال (throughput) آن در میزبان‌های masked و unmasked یکسان است. اما OpenVPN و IPsec که با AES-GCM پیکربندی شده‌اند، در میزبانی که فاقد AES-NI باشد، دچار افت سرعت می‌شوند. بنابراین دو تونل روی یک VPS مشابه می‌توانند رفتارهای بسیار متفاوتی داشته باشند؛ دانستن این نکته پیش از مقصر دانستن شبکه ضروری است.

چگونه وجود AES-NI را در یک VPS با معماری ARM بررسی کنم؟

هسته‌های ARM دارای AES-NI نیستند. آن‌ها از افزونه‌های رمزنگاری ARMv8 استفاده می‌کنند که همان کار را با دستورات متفاوتی انجام می‌دهند. دستور grep -m1 Features /proc/cpuinfo را اجرا کرده و به دنبال aes و pmull بگردید، زیرا در معماری aarch64 این موارد در بخش Features لیست می‌شوند و نه flags. مقدار OPENSSL_ia32cap در x86 هیچ معنایی در ARM ندارد. متغیر معادل آن در OpenSSL برای این معماری OPENSSL_armcap است و ساختار بیت‌های آن در فایل crypto/arm_arch.h در سورس‌کد OpenSSL تعریف شده است.