SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-13

VPSలో AES-NI ఉందో చూసి వేగాన్ని తిరిగి పొందండి

VPSలో AES-NI దాగి ఉందో తనిఖీ చేయండి, masked CPUID వల్ల AES-GCM throughputకు వచ్చే నష్టాన్ని కొలవండి, OPENSSL_ia32capతో fast pathను మళ్లీ సక్రియం చేయండి.

VPSలో AES-NI వాస్తవంగా మీకు అందించేది

VPSలో AES-NI అనేది AES (advanced encryption standard) యొక్క ఒక round ను hardwareలో నిర్వహించే ఆరు x86 instructions సమూహం. మీ provider CPU model ఈ instructions ను దాచిపెట్టినా, underlying siliconలో అవి ఉంటాయి. అయితే OpenSSL వాటిని గుర్తించలేక, ప్రతి byteకు సుమారు పది రెట్లు ఎక్కువ cycles అవసరమయ్యే software implementationకు మారుతుంది. ఒక commandతో ఈ feature ఉందో లేదో తనిఖీ చేయవచ్చు, రెండు commandsతో పనితీరు తేడాను కొలవచ్చు, అలాగే ఒక environment variableతో fast pathను మళ్లీ సక్రియం చేయడం తరచుగా సాధ్యమవుతుంది.

ఈ instructions AESENC, AESENCLAST, AESDEC, AESDECLAST, AESIMC మరియు AESKEYGENASSIST. Intel వీటిని 2010లో విడుదల చేసింది. తరువాత AMD కూడా వాటిని అందించింది. అందువల్ల మీరు rent చేసే అవకాశమున్న ఏ server CPUలోనైనా ఈ silicon సాధారణంగా ఉంటుంది. సహాయక instruction అయిన PCLMULQDQ carry-less multiplication నిర్వహిస్తుంది. Authentication tagను రూపొందించడానికి GCM (Galois/counter mode)కు ఇదే అవసరం. రెండూ అందుబాటులో ఉన్నప్పుడే AES-GCM వేగంగా పనిచేస్తుంది, ఎందుకంటే cipher మరియు tag వేర్వేరు పనులు.

VPSలో monitoringలో ఇది కనిపించే నాలుగు ప్రదేశాలు:

  • TLS (transport layer security) termination. AES-128-GCM లేదా AES-256-GCM అందించే web server తన bulk-crypto సమయాన్ని ఎక్కువగా AESలోనే వినియోగిస్తుంది.
  • Encrypted volumes. LUKS (Linux unified key setup) మరియు dm-crypt ప్రతి read, ప్రతి write సమయంలో kernelలో CPUపై aes-xts ను అమలు చేస్తాయి.
  • AES-based VPN traffic. AES-256-GCMతో OpenVPN మరియు AES-GCMతో IPsec రెండూ దీనిపై ఆధారపడతాయి.
  • Encrypted backups. server నుంచి బయటకు వెళ్లే ముందు streamను AESతో encrypt చేసే ఏ విధానమైనా ఇదే ఖర్చును భరిస్తుంది.

ఒక సాధారణ workloadపై దీని ప్రభావం అసలు ఉండదు. WireGuard తన data కోసం ChaCha20-Poly1305ను ఉపయోగిస్తుంది. అది AESను ఎప్పుడూ ఉపయోగించదు. అందువల్ల flag masked ఉన్న hostలో కూడా స్వయంగా నిర్వహించే WireGuard VPN అదే వేగంతో నడుస్తుంది. తక్కువ ఖర్చు VPS కోసం tunnel ఎంచుకునే ముందు WireGuardను OpenVPNతో పోల్చడంకు ఈ తేడా ఒక ఆచరణాత్మక కారణం.

మీ VPSలో AES-NI ఉందో లేదో ఎలా తనిఖీ చేయాలి

కర్నల్ CPUID feature bits ను /proc/cpuinfo లోకి కాపీ చేస్తుంది. అందువల్ల ఒక్క grep ఆదేశంతోనే విషయం తెలుస్తుంది.

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

aes ను ప్రింట్ చేసే ఏదైనా ఆదేశం, CPU ఈ guest కు AES-NI అందిస్తున్నదని సూచిస్తుంది. ఏమీ ప్రింట్ కాకపోతే, CPU AES-NI అందించడం లేదు. lscpu కూడా అదే flags ను చదువుతుంది. కాబట్టి రెండింటి ఫలితాలు ఎల్లప్పుడూ ఒకేలా ఉంటాయి. మీ సిస్టమ్‌లో ఇన్‌స్టాల్ అయి ఉన్నదాన్ని ఉపయోగించండి.

ఇప్పుడు మీరు ఏ CPUపై నడుస్తున్నారని host చూపిస్తుందో చూడండి.

grep -m1 'model name' /proc/cpuinfo

Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz లేదా AMD EPYC 7443P 24-Core Processor వంటి నిజమైన model string కనిపిస్తే, host భౌతిక CPU model ను మీకు అందిస్తోంది. QEMU Virtual CPU version 2.5+ లేదా Common KVM processor కనిపిస్తే, వేరే విధానం జరుగుతోంది. అర్థం చేసుకోవాల్సిన పరిస్థితి అదే.

siliconలో ఆ flag ఉన్నప్పటికీ అది ఎందుకు కనిపించదు

ప్రోగ్రామ్ CPUకు ఏ సామర్థ్యాలకు మద్దతు ఉందో అడగడానికి ఉపయోగించే instruction CPUID. Virtual machine లో CPUID ఎల్లప్పుడూ hypervisor వద్ద trap అవుతుంది. అందువల్ల guestకు ఏమి తెలియజేయాలో hypervisor నిర్ణయిస్తుంది. చాలా panels ఈ నిర్ణయాన్ని guest CPU modelగా చూపిస్తాయి. qemu64 మరియు kvm64 సాధారణ baseline models. వాటి feature setలో AES-NI లేదా SSSE3 ఉండవు. కాబట్టి physical host ప్రస్తుత EPYC అయినప్పటికీ guestకు aes flag కనిపించదు. VPS అనేది మరొకరి hardwareపై నడిచే guest. అందువల్ల అది report చేసే ప్రతి featureను ఒక స్థాయి పైభాగం నిర్ణయిస్తుంది. ఈ layering మీకు కొత్త అయితే, ముందుగా VPS అంటే ఏమిటి చూడండి.

వేర్వేరు processors ఉన్న machines మధ్య live migration పనిచేయాలంటే guestకు destinationలో లేని feature ఏదీ తెలియకూడదు. అందుకే hosts ఉద్దేశపూర్వకంగా generic modelను ఎంచుకుంటాయి. దీని ప్రభావం మీపై పడుతుంది. మీ kernel మరియు మీ OpenSSL copy రెండూ startup సమయంలో masked CPUID విలువను ఒక్కసారి చదువుతాయి. ఆ తరువాత process కొనసాగినంతకాలం slow code pathనే ఎంచుకుంటాయి.

దీనికి మూలస్థాయిలో పరిష్కారం host-side setting. QEMU పరంగా అది -cpu host, AES-NIని కలిగి ఉన్న named model, లేదా modelకు జోడించిన explicit +aes కావచ్చు. వీటిలో ఏదీ guest లోపల నుంచి set చేయలేరు. Support ticket తెరవడం, లేదా hypervisor CPU modelను pass through చేసే planను ఎంచుకోవడం, దీర్ఘకాలిక పరిష్కారం.

openssl speed తో వ్యత్యాసాన్ని కొలవండి

ప్రచురితమైన benchmark ను ధృవీకరించకుండా నమ్మవద్దు. మీ సర్వర్ వాస్తవంగా negotiate చేసే cipher ను మీరే అమలు చేయండి.

openssl version
openssl speed -evp aes-128-gcm

ఫలితంలోని row కు AES-128-GCM అనే label ఉంటుంది. అందులో ఆరు block sizes కోసం throughput ఉంటుంది. యూనిట్ 1000 bytes per second. 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 నుంచే వస్తుంది. ప్రారంభంలోని ~ అంటే “ఈ bits ను clear చేయండి” అని అర్థం. Bit 57 AES-NI ను సూచిస్తుంది. Bit 33 PCLMULQDQ ను సూచిస్తుంది. కాబట్టి 0x200000200000000 ఈ రెండు bits ను మాత్రమే సూచిస్తుంది. మొదటి విలువ కంటే రెండవ విలువ చాలా తక్కువగా ఉంటే, మీ system లో AES-NI సరిగా పనిచేస్తోంది. మీ పరీక్ష పూర్తయింది. రెండు విలువలు సమానంగా ఉంటే, OpenSSL ఇప్పటికే software path ను ఉపయోగిస్తోంది. ఎందుకంటే clear చేయాల్సిన flag అక్కడ లేదు.

ChartAES-128-GCM throughput, one core, 8192-byte blocks (representative published figures)
The data behind this chart
[
  {
    "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 ప్రతి byte కు సుమారుగా 0.7 cycles తో నడుస్తుంది. Software fallback ప్రతి byte కు సుమారుగా 11.0 cycles తో నడుస్తుంది. ఒక core పై ఇది సుమారుగా 4,850 MB/s కు, software fallback 310 MB/s కు సమానం. మీ సర్వర్‌ను వివరించే ఏకైక విలువ పైన అమలు చేసిన రెండు commands నుంచే వస్తుంది. ఇదే విధానాన్ని మిగతా system కు కూడా వర్తింపజేయండి. కాబట్టి ఏదైనా plan గురించి నిర్ణయానికి రాకముందు, దీనిని VPS ను పునరావృతంగా benchmark చేసే విధానం తో కలిపి పరిశీలించండి.

OPENSSL_ia32cap తో సామర్థ్యాలను మళ్లీ ప్రారంభించండి

ఇక్కడే చాలామందికి ఆశ్చర్యం కలుగుతుంది. AES-NI సూచనలు privileged కావు, అలాగే hypervisor వాటిని trap చేయదు. CPUID మాత్రమే trap అవుతుంది. అందువల్ల host మీ guest కు AES-NI లేదని తెలియజేయగలదు, కానీ AESENC మాత్రం native వేగంతో పూర్తి సామర్థ్యంతో అమలవుతూనే ఉంటుంది. Software CPUID ను అడిగి తప్పు సమాధానం పొందుతుంది కాబట్టి fast path ను దాటవేస్తుంది. ఆ instruction స్వయంగా ఎప్పుడూ పనిచేయడం ఆపలేదు.

OpenSSL CPU తరఫున సమాధానం ఇవ్వడానికి మిమ్మల్ని అనుమతిస్తుంది. OPENSSL_ia32cap లోని సాధారణ hexadecimal విలువ capability vector ను mask చేయదు; దాని స్థానంలో పూర్తిగా రాస్తుంది.

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

ఈ run, plain run కంటే అనేక రెట్లు వేగంగా ఉంటే, ఆ silicon లో AES-NI ఉందని, మీ host దాన్ని దాచిపెడుతోందని అర్థం. ఇది ముందుగా diagnosis కోసం ఉపయోగించే పద్ధతి. OpenSSL విషయంలో ఇది పరిష్కారంగానూ పనిచేస్తుంది.

ఆ hexadecimal విలువను ఎలా నిర్మించాలి

మొదటి logical vector లో CPUID leaf 1 EDX ను low 32 bits లో, leaf 1 ECX ను high 32 bits లో pack చేస్తారు. Low half లో bit 24 FXSR, bit 25 SSE, bit 26 SSE2; ఇవి కలిసి 0x07000000 ను ఇస్తాయి. Upper half లో bit 33 PCLMULQDQ, bit 41 SSSE3, bit 57 AES-NI; ఇవి కలిసి 0x02000202 ను ఇస్తాయి. రెండింటినీ కలిపితే అది 0x0200020207000000 అవుతుంది. ఈ జాబితాలో SSSE3 ఉండటానికి కారణం, OpenSSL యొక్క PCLMULQDQ ఆధారిత GHASH bytes ను మార్చడానికి pshufb ను ఉపయోగించడం. Generic guest CPU model AES-NIతో పాటు SSSE3ను కూడా దాచిపెడుతుంది.

ఇక్కడ రెండు హెచ్చరికలు వర్తిస్తాయి. మీరు ఉద్దేశపూర్వకంగా రెండింటినీ trigger చేయవచ్చు.

మొదటి vector ను మాత్రమే set చేస్తే తరువాతి vectors సున్నాగా ఉంటాయి. దాంతో AVX2 మరియు AVX-512 code paths నిలిచిపోతాయి. ఇక్కడ ఇది ఉద్దేశపూర్వకమే. Mask చేసిన guest లో AVX bits ను బలవంతంగా enable చేయవద్దు. ఎందుకంటే AVX registers కోసం operating system XCR0 లో extended state ను enable చేయాలి. అదే masked CPUID ఆధారంగా మీ kernel దాన్ని నిరాకరించింది. ఆ తర్వాత VEX-encoded instruction undefined-opcode fault ను కలిగించి process ను ముగిస్తుంది.

నిజంగా AES-NI లేని core లో దాన్ని force చేస్తే process వెంటనే ముగుస్తుంది:

Illegal instruction (core dumped)

ఆ core లో అమలు చేయడానికి అలాంటి instruction ఏదీ లేనందున, AESENC undefined-opcode fault ను కలిగిస్తుంది. కొన్ని server firmware లు తదుపరి reset వరకు hardwareలో AES-NIని కూడా disable చేయగలవు. అప్పుడు కనిపించే లక్షణం ఇదే ఉంటుంది. ఏ సందర్భంలోనైనా సమాధానం వేరే 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 ను నిజంగా AES-NI లేని host కు ఎప్పుడైనా migrate చేస్తే, దాని మొదటి TLS connection సమయంలో nginx illegal instruction తో ముగుస్తుంది. దీన్ని మీ runbook లో నమోదు చేయండి. లేదా override ను production నుంచి పూర్తిగా దూరంగా ఉంచి, ticket తెరిచేటప్పుడు కారణాన్ని నిరూపించడానికి మాత్రమే ఉపయోగించండి.

override సరిచేయలేనివి

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 పరిధిలో ఉంటుంది. అది లేకపోతే తక్కువ వందల MiB/s పరిధిలో ఉంటుంది. తమ సొంత detection ను ఉపయోగించే language runtimes కూడా ఇదే విధంగా అందుబాటులో ఉండవు. Go మరియు Java వాటిలో ఉన్నాయి. Go యొక్క crypto/aes నేరుగా CPUID ను తనిఖీ చేస్తుంది. ఆ bit clear గా ఉంటే, అది తన constant-time software implementation ను నిశ్శబ్దంగా ఉపయోగిస్తుంది. మీ TLS ను terminate చేసే service Go binary అయితే, OpenSSL variable దానిపై ఎలాంటి ప్రభావం చూపదు.

AES-NI అందుబాటులో లేకపోతే ChaCha20కు ప్రాధాన్యం ఇవ్వండి

ChaCha20-Poly1305 సాధారణ softwareలో వేగంగా పనిచేసేలా రూపొందించబడింది. ఉపయోగించగల AES-NI లేని coreలో ఇది సాధారణంగా AES-GCM కంటే చాలా వేగంగా ఉంటుంది. కాబట్టి అలాంటి hostలో AESకు ప్రాధాన్యం ఇవ్వడం నిలిపివేయడం సముచితం.

OpenSSL 1.1.1 లేదా కొత్త versionతో build చేసిన nginx 1.19.4 లేదా కొత్త version కోసం:

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కు ప్రత్యేక directive లేదు. అందువల్ల nginx ఆ stringను ఎలాంటి checking లేకుండా నేరుగా OpenSSLకు పంపుతుంది. అక్కడ typo ఉన్నా అది ఎలాంటి error లేకుండా అంగీకరించబడుతుంది. 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 hosts వేర్వేరు extensions ఉపయోగిస్తాయి

AES-NI అనేది x86 కోసం మాత్రమే. ARM VPS, అదే పనిని చేసే ప్రత్యేక instruction set అయిన ARMv8 cryptographic extensions ను ఉపయోగిస్తుంది. aarch64 లో flags, flags కింద కాకుండా Features కింద ఉంటాయి:

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 value అక్కడ ఉపయోగపడదు. ఆచరణలో VPS hosts గా విక్రయించే ARM server cores ఈ extensions ను అందుబాటులో ఉంచుతాయి. కాబట్టి masked-feature సమస్య ప్రధానంగా x86కు సంబంధించినదే.

వైఫల్య పరిస్థితులు, మీరు చూసే strings

aes లో /proc/cpuinfo లేదు, మరియు బలవంతంగా అమలు చేసినప్పుడు వేగం చాలా ఎక్కువగా ఉంది. Host CPUID ను mask చేస్తోంది. Model name సాధారణంగా చూపబడుతోందో నిర్ధారించండి. తరువాత hypervisor చూపించే guest CPU model ఏమిటో provider ను అడగండి.

aes లో /proc/cpuinfo లేదు, మరియు బలవంతంగా అమలు చేసినప్పుడు Illegal instruction ముద్రించబడుతోంది. ఆ instructions నిజంగానే లేవు లేదా firmware వాటిని నిలిపివేసింది. Workload ను వేరే host కు మార్చండి.

aes ఉంది, కానీ throughput ఇప్పటికీ తక్కువగా ఉంది. మీరు 8192-byte column ను చదువుతున్నారో నిర్ధారించండి. ఆ core ను మరే ఇతర ప్రక్రియ ఉపయోగించడం లేదో కూడా పరిశీలించండి. Shared plan లో noisy neighbour, CPU feature లేనట్టే కనిపించవచ్చు. రోజులో వేర్వేరు సమయాల్లో test ను రెండుసార్లు అమలు చేసిన తర్వాతే తేడా తెలుస్తుంది.

Masked run మరియు normal run ఒకే సంఖ్యను ఇస్తున్నాయి. OpenSSL ఇప్పటికే software path ను ఉపయోగిస్తోంది. ఈ ఫలితమే అసలు నిర్ధారణ. ఇది test లోపం కాదు.

Nested virtualisation సమాధానాన్ని ఒక స్థాయి దిగువన మారుస్తుంది. Guest లోని guest కు మధ్యస్థ layer pass through చేయాలని ఎంచుకున్న CPUID మాత్రమే లభిస్తుంది. అక్కడ AES-NI గుర్తించకుండా కోల్పోవడం సులభం. మీరు VPSలో nested virtual machines నడిపితే, మీరు అద్దెకు తీసుకున్న machine పై మాత్రమే కాకుండా inner guest లో కూడా flag ను పరిశీలించండి.

FAQ

నా VPS లో /proc/cpuinfoలో aes flag ఎందుకు లేదు?

Hypervisor సాధారణ guest CPU model ను చూపిస్తున్నందువల్ల ఇది జరుగుతుంది. qemu64 మరియు kvm64 feature set లలో AES-NI ఉండదు. అందువల్ల భౌతిక processor ఏదైనా CPUID దాన్ని అందుబాటులో లేదని చూపిస్తుంది. వేర్వేరు CPUలు ఉన్న machines మధ్య నడుస్తున్న guest ను migrate చేయడానికి hosts ఇలా చేస్తాయి. 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 చేస్తుందా, లేక అలా ఉన్నట్లు మాత్రమే చూపిస్తుందా?

ఇది నిజమైన instructions ను enable చేస్తుంది. AES-NI instructions కు privileged access అవసరం లేదు. Hypervisor వాటిని ఎప్పుడూ trap చేయదు. అందువల్ల CPUID ఏమి చూపించినా AESENC nativeగా execute అవుతుంది. CPUID instruction మాత్రమే intercept అవుతుంది. OPENSSL_ia32cap కు plain hexadecimal value ను set చేస్తే, CPUID నుంచి OpenSSL పొందిన సమాధానం replace అవుతుంది. దాంతో OpenSSL hardware code path ను ఎంచుకుంటుంది. తరువాత hardware దాన్ని పూర్తి వేగంతో అమలు చేస్తుంది. Siliconలో instructions నిజంగా లేకపోతే, మొదటి AES operation వద్ద process Illegal instruction (core dumped) తో ముగుస్తుంది.

ఈ override నా LUKS encrypted volume ను వేగవంతం చేస్తుందా?

లేదు. OPENSSL_ia32cap ను OpenSSL మాత్రమే చదువుతుంది. మరే ఇతర భాగం దాన్ని చదవదు. LUKS మరియు dm-crypt kernel crypto API ను ఉపయోగిస్తాయి. Feature bit clearగా ఉన్నప్పుడు ఆ APIలోని 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 తో కొలవండి. Flag చూపించే hostతో పోల్చేటప్పుడు aes-xts 256b row ను పరిశీలించండి.

AES-NI flag లేకపోవడం WireGuard ను నెమ్మదింపజేస్తుందా?

లేదు. WireGuard మొత్తం data కోసం ChaCha20-Poly1305 ను ఉపయోగిస్తుంది. ఇది AES instructions ను ఎప్పుడూ ఉపయోగించదు. అందువల్ల masked host మరియు unmasked host మధ్య దాని throughput ఒకేలా ఉంటుంది. AES-GCMతో configure చేసిన OpenVPN మరియు IPsec, AES-NI లేని hostలో throughput కోల్పోతాయి. కాబట్టి ఒకే VPSలోని రెండు tunnels చాలా భిన్నంగా పనిచేయవచ్చు. Networkను కారణంగా భావించే ముందు ఈ విషయం తెలుసుకోవడం ఉపయోగకరం.

ARM VPSలో AES-NI ఉందో లేదో ఎలా తనిఖీ చేయాలి?

ARM coresలో AES-NI ఉండదు. వాటిలో ARMv8 cryptographic extensions ఉంటాయి. ఇవి వేర్వేరు instructionsతో అదే పని చేస్తాయి. grep -m1 Features /proc/cpuinfo ను అమలు చేసి aes మరియు pmull కోసం చూడండి. aarch64 వాటిని Features కింద జాబితా చేస్తుంది, flags కింద కాదు. ARMలో x86 OPENSSL_ia32cap valueకు అర్థం లేదు. అక్కడ OpenSSLకు సమానమైన variable OPENSSL_armcap. దాని bit layout OpenSSL sourceలోని crypto/arm_arch.hలో నిర్వచించబడింది.

#aes-ni#cpu#openssl#encryption#performance