VPS-ல் AES-NI வசதியை சரிபார்ப்பது மற்றும் செயல்படுத்துவது

VPS-ல் AES-NI உங்களுக்கு என்ன பயனைத் தருகிறது

VPS-ல் உள்ள AES-NI என்பது ஆறு x86 கட்டளைகளின் தொகுப்பாகும். இவை வன்பொருள் (hardware) மட்டத்தில் AES (advanced encryption standard)-ன் ஒரு சுற்றை (round) நிறைவேற்றுகின்றன. உங்கள் சேவை வழங்குநரின் CPU மாதிரி இவற்றை மறைத்தாலும், அதன் சிலிக்கான் கட்டமைப்பில் அவை இருக்கும். ஆனால், OpenSSL-ஆல் அவற்றைக் கண்டறிய முடியாது என்பதால், அது மென்பொருள் அடிப்படையிலான செயல்பாட்டிற்கு மாறிவிடும். இது ஒரு பைட்டிற்கு சுமார் பத்து மடங்கு அதிக CPU சுழற்சிகளை (cycles) எடுத்துக்கொள்ளும். ஒரு கட்டளை மூலம் இந்த வசதி உள்ளதா என்பதைச் சரிபார்க்கலாம், இரண்டு கட்டளைகள் மூலம் அதன் வேக வித்தியாசத்தை அளவிடலாம், மேலும் ஒரு environment variable மூலம் வேகமான பாதையை மீண்டும் கட்டாயப்படுத்தலாம்.

இந்தக் கட்டளைகள் AESENC, AESENCLAST, AESDEC, AESDECLAST, AESIMC மற்றும் AESKEYGENASSIST ஆகும். Intel இவற்றை 2010-ல் அறிமுகப்படுத்தியது, அதைத் தொடர்ந்து AMD-யும் வெளியிட்டது. எனவே, நீங்கள் வாடகைக்கு எடுக்கும் எந்தவொரு சர்வர் CPU-விலும் இந்த சிலிக்கான் வசதி இருக்கும். இதனுடன் தொடர்புடைய PCLMULQDQ என்ற கட்டளை, carry-less multiplication-ஐச் செய்கிறது. GCM (Galois/counter mode) அதன் authentication tag-ஐ உருவாக்க இதுவே தேவைப்படுகிறது. இவை இரண்டும் கிடைக்கும்போது மட்டுமே 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-அடிப்படையிலான VPN traffic. AES-256-GCM-ஐப் பயன்படுத்தும் OpenVPN மற்றும் AES-GCM-ஐப் பயன்படுத்தும் IPsec ஆகிய இரண்டுமே இதைச் சார்ந்தே உள்ளன.
• Encrypted backups. ஒரு stream-ஐ சர்வரை விட்டு வெளியேறும் முன் AES மூலம் encrypt செய்யும் எந்தவொரு செயலும் அதே செலவை (cost) எதிர்கொள்கிறது.

பொதுவான ஒரு பணிச்சுமை (workload) இதனால் பாதிக்கப்படுவதில்லை. WireGuard அதன் தரவுகளுக்கு ChaCha20-Poly1305-ஐப் பயன்படுத்துகிறது, அது AES-ஐத் தொடுவதில்லை. எனவே, இந்த flag மறைக்கப்பட்ட ஒரு host-லும் self-hosted WireGuard VPN அதே வேகத்தில் இயங்கும். மலிவான VPS-க்கு ஒரு tunnel-ஐத் தேர்ந்தெடுக்கும் முன் 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-களைத்தான் வாசிக்கிறது, எனவே இரண்டு கட்டளைகளும் ஒரே முடிவையே தரும். உங்கள் கணினியில் எது உள்ளதோ அதைப் பயன்படுத்தவும்.

இப்போது, நீங்கள் எந்த 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 தனது physical CPU model-ஐ உங்களுக்கு வழங்குகிறது என்று அர்த்தம். QEMU Virtual CPU version 2.5+ அல்லது Common KVM processor என்று இருந்தால், வேறு ஏதோ நடக்கிறது என்று பொருள்; அந்தச் சூழலைப் புரிந்துகொள்வது அவசியமானது.

சிலிக்கானில் இருந்தும் ஏன் flag விடுபடுகிறது

CPUID என்பது ஒரு program தான் எதை ஆதரிக்கிறது என்பதை CPU-விடம் கேட்கப் பயன்படுத்தும் instruction ஆகும். ஒரு virtual machine-க்குள், CPUID எப்போதும் hypervisor-க்கு trap ஆகும், எனவே guest-க்கு என்ன தெரிய வேண்டும் என்பதை hypervisor-தான் தீர்மானிக்கிறது. பெரும்பாலான panels அந்த முடிவை ஒரு guest CPU model-ஆக வெளிப்படுத்துகின்றன. qemu64 மற்றும் kvm64 ஆகியவை பொதுவான baseline மாதிரிகள், இவை எதிலும் AES-NI அல்லது SSSE3 அம்சங்கள் இல்லை, எனவே physical host தற்போதைய EPYC-ஆக இருந்தாலும் guest-க்கு எந்த aes flag-ம் தெரியாது. ஒரு VPS என்பது வேறொருவரின் hardware-ல் இயங்கும் guest, எனவே அது காட்டும் ஒவ்வொரு அம்சமும் ஒரு படி மேலே எடுக்கப்பட்ட முடிவாகும். இந்த அடுக்கு முறை (layering) உங்களுக்குப் புதியது என்றால், VPS என்றால் என்ன என்பதிலிருந்து தொடங்கவும்.

Hosts வேண்டுமென்றே ஒரு பொதுவான மாதிரியைத் தேர்ந்தெடுக்கின்றன, ஏனெனில் வெவ்வேறு processors கொண்ட machines-க்கு இடையே live migration செய்ய வேண்டுமானால், சேருமிடத்தில் (destination) இல்லாத ஒரு அம்சத்தைப் பற்றி guest-க்குத் தெரிந்திருக்கக்கூடாது. இதற்கான இழப்பை நீங்கள் சந்திக்கிறீர்கள். உங்கள் kernel மற்றும் உங்கள் OpenSSL நகல் ஆகிய இரண்டும் அந்த masked CPUID-ஐ தொடக்கத்தில் ஒருமுறை படிக்கின்றன, பின்னர் process முடியும் வரை மெதுவான code path-ஐயே பயன்படுத்துகின்றன.

இதற்கான தீர்வு host-side அமைப்பில் உள்ளது: QEMU அடிப்படையில் -cpu host, அதாவது AES-NI-ஐ உள்ளடக்கிய ஒரு குறிப்பிட்ட மாதிரி அல்லது மாதிரியுடன் சேர்க்கப்பட்ட ஒரு தெளிவான +aes. இதை நீங்கள் guest-க்குள் இருந்து அமைக்க முடியாது. ஒரு support ticket-ஐத் திறப்பது அல்லது hypervisor-ஐ CPU model-ஐ அப்படியே கடந்து செல்ல அனுமதிக்கும் (pass-through) ஒரு திட்டத்தைத் தேர்ந்தெடுப்பதே நிரந்தரமான தீர்வாகும்.

openssl speed மூலம் இடைவெளியை அளவிடுதல்

வெளியிடப்பட்ட benchmark முடிவுகளை அப்படியே நம்ப வேண்டாம். உங்கள் server-ல் எந்த cipher பயன்படுத்தப்படுகிறதோ, அதை நீங்களே இயக்கிப் பாருங்கள்.

openssl version
openssl speed -evp aes-128-gcm

முடிவுகள் அடங்கிய வரிசை AES-128-GCM என்று பெயரிடப்பட்டிருக்கும். இது ஆறு வெவ்வேறு block அளவுகளில், வினாடிக்கு 1000 bytes என்ற அலகில் throughput-ஐக் காட்டும். கோப்பு பதிவிறக்கத்தின் வேகத்தை அறிய 8192-byte நெடுவரிசையைப் பார்க்கவும்; ஏனெனில் 16-byte நெடுவரிசை என்பது ஒவ்வொரு அழைப்பிற்கும் ஏற்படும் overhead-ஐ மட்டுமே குறிக்கும், இது கோப்பு பதிவிறக்கத்தைப் பற்றி எதையும் தெரிவிக்காது.

இப்போது AES-NI மற்றும் PCLMULQDQ ஆகியவற்றை software-ல் முடக்கிவிட்டு அதே கட்டளையை இயக்கவும்:

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

அந்த மதிப்பு OpenSSL-ன் capability vector ஆவணத்திலிருந்து பெறப்பட்டது. தொடக்கத்தில் உள்ள ~ என்பது "இந்த bits-ஐ நீக்கு" என்று பொருள். Bit 57 என்பது AES-NI மற்றும் bit 33 என்பது PCLMULQDQ ஆகும், எனவே 0x200000200000000 என்பது அந்த இரண்டையும் மட்டும் குறிக்கும். முதல் மதிப்பை விட இரண்டாவது மதிப்பு மிகக் குறைவாக இருந்தால், உங்கள் server-ல் AES-NI சரியாகச் செயல்படுகிறது என்று அர்த்தம், உங்கள் பணி முடிந்தது. இரண்டு எண்களும் சமமாக இருந்தால், OpenSSL ஏற்கனவே software பாதையில்தான் இயங்கிக்கொண்டிருந்தது என்று பொருள், ஏனெனில் அந்த 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 பாதை தோராயமாக 0.7 cycles per byte வேகத்திலும், software fallback தோராயமாக 11.0 வேகத்திலும் இயங்கும். இது ஒரு core-ல் தோராயமாக 4,850 MB/s மற்றும் 310 MB/s என்ற அளவில் இருக்கும். மேலே நீங்கள் இயக்கிய இரண்டு கட்டளைகளே உங்கள் server-ன் உண்மையான செயல்திறனைக் காட்டும். இதே அணுகுமுறையை machine-ன் பிற பகுதிகளுக்கும் பயன்படுத்தலாம், எனவே ஒரு திட்டத்தைப் பற்றி முடிவெடுக்கும் முன் VPS-ஐ benchmark செய்வதற்கான மீண்டும் செய்யக்கூடிய வழிமுறை உடன் இதை இணைத்துப் பார்க்கவும்.

OPENSSL_ia32cap மூலம் பிட்களை மீண்டும் செயல்படுத்துதல்

இது பலரை ஆச்சரியப்படுத்தும் ஒரு விஷயம். AES-NI கட்டளைகள் (instructions) சலுகை பெறாதவை (unprivileged), மேலும் hypervisor அவற்றை trap செய்வதில்லை. CPUID மட்டுமே trap செய்யப்படுகிறது. எனவே, AES-NI இல்லை என்று உங்கள் guest-க்கு host தவறான தகவலைத் தந்தாலும், AESENC தொடர்ந்து முழு வேகத்தில் இயங்கிக்கொண்டே இருக்கும். CPUID-யிடம் கேட்டு தவறான பதிலைப்பெற்றதால், மென்பொருள் வேகமான பாதையை (fast path) தவிர்த்துவிடுகிறது. ஆனால், அந்த கட்டளை ஒருபோதும் செயல்படுவதை நிறுத்துவதில்லை.

OpenSSL, CPU-க்கு பதிலாக நீங்களே பதில் அளிக்க அனுமதிக்கிறது. OPENSSL_ia32cap-ல் உள்ள ஒரு எளிய பதினறும (hexadecimal) மதிப்பு, capability vector-ஐ மறைப்பதற்குப் பதிலாக, அதை மேலெழுதும் (overwrite).

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

அந்த இயக்கம் (run), சாதாரண இயக்கத்தை விட பல மடங்கு வேகமாக இருந்தால், உங்கள் hardware-ல் AES-NI உள்ளது, ஆனால் host அதை மறைக்கிறது என்று அர்த்தம். இது ஒரு கண்டறியும் முறை (diagnosis). OpenSSL-ஐப் பொறுத்தவரை, இதுவே ஒரு தீர்வாகவும் அமைகிறது.

இரண்டு எச்சரிக்கைகள் உள்ளன, இரண்டையும் நீங்கள் வேண்டுமென்றே தூண்ட முடியும்.

முதல் vector-ஐ மட்டும் அமைத்தால், மற்ற vector-கள் பூஜ்ஜியமாகவே இருக்கும், இது AVX2 மற்றும் AVX-512 code path-களை முடக்கிவிடும். இது இங்கே வேண்டுமென்றே செய்யப்படுகிறது. மறைக்கப்பட்ட (masked) guest-ல் AVX பிட்களை கட்டாயப்படுத்த முயற்சிக்காதீர்கள். ஏனெனில், AVX registers-க்கு XCR0-ல் extended state-ஐ இயக்க operating system தேவைப்படுகிறது, ஆனால் அதே மறைக்கப்பட்ட CPUID-யை அடிப்படையாகக் கொண்டு உங்கள் kernel அதை நிராகரித்துவிட்டது. ஒரு VEX-encoded கட்டளை, undefined-opcode பிழையை (fault) உண்டாக்கி, process-ஐ முடித்துவிடும்.

உண்மையிலேயே AES-NI இல்லாத ஒரு core-ல் அதை கட்டாயப்படுத்தினால், process உடனடியாக முடிந்துவிடும்:

Illegal instruction (core dumped)

இது AESENC உண்டாக்கும் undefined-opcode பிழையாகும், ஏனெனில் அந்த 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

கடைசி கட்டளை அந்த variable-ஐ உங்களுக்குத் திரையில் காட்ட வேண்டும். நீங்கள் எதற்கு ஒப்புக்கொள்கிறீர்கள் என்பதைப் புரிந்துகொள்ளுங்கள்: அந்த server, AES-NI இல்லாத ஒரு host-க்கு மாற்றப்பட்டால், nginx அதன் முதல் TLS இணைப்பின்போதே illegal instruction பிழையுடன் செயலிழந்துவிடும். இதை உங்கள் runbook-ல் குறித்துக்கொள்ளுங்கள், அல்லது production சூழலில் இந்த override-ஐத் தவிர்த்துவிட்டு, ticket எழுப்பும்போது ஆதாரத்திற்காக மட்டும் இதைப் பயன்படுத்தவும்.

இந்த override எதைச் சரிசெய்யாது

OPENSSL_ia32cap என்பது OpenSSL-ஐ மட்டுமே சென்றடையும், மற்ற எதையும் பாதிக்காது. மற்ற மென்பொருள்கள் அனைத்தும் அவற்றின் சொந்த feature detection-ஐ இயக்குகின்றன, இந்த variable-ஐ அவை வாசிப்பதில்லை.

Kernel என்பது முக்கியமான ஒரு சூழல். dm-crypt மற்றும் LUKS ஆகியவை kernel crypto API-ஐப் பயன்படுத்துகின்றன. CPU feature bit இல்லாதபோது aesni_intel module ஏற்றுவதை அவை மறுக்கின்றன:

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

இதற்கு user-space variable எதுவும் இல்லை. Kernel ஆனது boot-ன் போது ஒருமுறை மட்டுமே CPUID-ஐ வாசிக்கும். நீங்கள் வேறொரு host-ல் reboot செய்யும் வரை அந்த முடிவு மாறாது. எனவே, OpenSSL என்ன செய்தாலும் உங்கள் encrypted volume மென்பொருள் சார்ந்த cipher-லேயே இருக்கும். நீங்கள் உண்மையில் என்ன பெறுகிறீர்கள் என்பதை அளவிடவும்:

sudo cryptsetup benchmark -c aes-xts -s 256

aes-xts 256b வரிசையானது hardware AES இருந்தால் ஆயிரக்கணக்கான MiB/s வேகத்தையும், அது இல்லையெனில் நூற்றுக்கணக்கான MiB/s வேகத்தையும் காட்டும். Go மற்றும் Java உள்ளிட்ட சொந்த detection வசதி கொண்ட language runtimes-ம் இந்த மாற்றத்திற்கு அப்பாற்பட்டவை. Go-வின் crypto/aes நேரடியாக CPUID-ஐச் சரிபார்க்கிறது. அந்த bit இல்லை என்றால், அது அமைதியாகத் தனது constant-time மென்பொருள் செயல்பாட்டைப் பயன்படுத்திக்கொள்ளும். உங்கள் TLS-ஐ முடிக்கும் service ஒரு Go binary ஆக இருந்தால், OpenSSL variable-ஆல் எந்த மாற்றமும் ஏற்படாது.

AES-NI வசதி இல்லையெனில், ChaCha20-ஐத் தேர்ந்தெடுக்கவும்

ChaCha20-Poly1305 மென்பொருள் அடிப்படையிலான செயல்பாட்டில் வேகமானதாக இருக்கும் வகையில் வடிவமைக்கப்பட்டுள்ளது. AES-NI வசதி இல்லாத processor-களில், இது 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-ஐக் குறிக்கும். இதில் nginx-க்குத் தனிப்பட்ட directive கிடையாது; இது string-ஐ நேரடியாக OpenSSL-க்கு அனுப்பிவிடும். எனவே, இதில் ஏதேனும் எழுத்துப் பிழை இருந்தால் அது கண்டறியப்படாமல் ஏற்றுக்கொள்ளப்படும். configuration-ஐ 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 காட்டப்படும். இந்த மாற்றத்தைச் செயல்படுத்துவதற்கு முன், அதே server-ல் openssl speed -evp chacha20-poly1305-ஐ இயக்கி, AES-உடன் ஒப்பிட்டுப் பார்த்து, கிடைக்கும் முடிவுகளின் அடிப்படையில் முடிவெடுக்கவும்.

ARM hosts வெவ்வேறு extensions-களைப் பயன்படுத்துகின்றன

AES-NI என்பது x86-க்கு மட்டுமே உரியது. ஒரு ARM VPS, ARMv8 cryptographic extensions-ஐப் பயன்படுத்துகிறது; இது அதே பணியைச் செய்யும் ஒரு தனித்துவமான instruction set ஆகும். aarch64-ல், flags-கள் flags-க்கு பதிலாக Features-ன் கீழ் அமைகின்றன:

grep -m1 Features /proc/cpuinfo

aes மற்றும் pmull ஆகியவற்றைத் தேடவும். PCLMULQDQ-க்கு இணையான ARM அம்சம் pmull ஆகும், அதே காரணத்திற்காக GCM-க்கு இது தேவைப்படுகிறது. ARM-ல் OpenSSL-ன் override variable என்பது OPENSSL_armcap ஆகும். இதற்கான bit layout, OpenSSL source-ல் crypto/arm_arch.h-ல் வரையறுக்கப்பட்டுள்ளது, எனவே இந்த வழிகாட்டியில் உள்ள x86 hex மதிப்பு அங்கு செல்லாது. நடைமுறையில், VPS hosts-ஆக விற்கப்படும் ARM server cores இந்த extensions-களை வெளிப்படுத்துகின்றன, எனவே masked-feature சிக்கல் பெரும்பாலும் x86 தளத்தில் மட்டுமே நிகழ்கிறது.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் சரங்கள் (strings)

aes என்பது /proc/cpuinfo-ல் இல்லை, மேலும் கட்டாயப்படுத்தப்பட்ட இயக்கம் (forced run) மிக வேகமாக உள்ளது. ஹோஸ்ட் CPUID-ஐ மறைக்கிறது (masking). மாடல் பெயர் பொதுவானதாக (generic) உள்ளதா என்பதை உறுதிப்படுத்தவும், பின்னர் உங்கள் ஹைப்பர்வைசர் எந்த guest CPU மாடலை வழங்குகிறது என்று உங்கள் சேவை வழங்குநரிடம் கேட்கவும்.

aes என்பது /proc/cpuinfo-ல் இல்லை, மேலும் கட்டாயப்படுத்தப்பட்ட இயக்கம் Illegal instruction-ஐ அச்சிடுகிறது. இந்த அறிவுறுத்தல்கள் (instructions) உண்மையில் இல்லை அல்லது firmware அவற்றை முடக்கியுள்ளது. பணிச்சுமையை (workload) வேறொரு ஹோஸ்டிற்கு மாற்றவும்.

aes உள்ளது, ஆனால் செயல்திறன் (throughput) இன்னும் குறைவாக உள்ளது. நீங்கள் 8192-byte நெடுவரிசையைப் படிக்கிறீர்களா என்பதையும், அந்த core-ஐ வேறு எதுவும் பயன்படுத்தவில்லை என்பதையும் சரிபார்க்கவும். பகிரப்பட்ட திட்டத்தில் (shared plan), நீங்கள் வெவ்வேறு நேரங்களில் இரண்டு முறை சோதனையை இயக்கும் வரை, ஒரு 'noisy neighbour' என்பது விடுபட்ட CPU அம்சத்தைப் போலவே தோன்றும்.

Masked run மற்றும் சாதாரண run ஆகிய இரண்டும் ஒரே எண்ணைத் தருகின்றன. OpenSSL ஏற்கனவே மென்பொருள் பாதையில் (software path) இருந்தது. அந்த முடிவுதான் கண்டறிதல், சோதனையில் உள்ள தவறு அல்ல.

Nested virtualisation ஒரு நிலை கீழே பதிலை மாற்றுகிறது. ஒரு guest-க்குள் இருக்கும் மற்றொரு guest, இடைநிலை அடுக்கு (middle layer) எதை வழங்குகிறதோ அந்த CPUID-ஐயே பெறுகிறது. அங்கு AES-NI அம்சத்தை கவனிக்காமல் இழப்பது எளிது. நீங்கள் VPS-ல் nested virtual machines இயக்கினால், நீங்கள் வாடகைக்கு எடுத்த இயந்திரத்தில் மட்டுமல்லாமல், உள்ளே இருக்கும் guest-க்குள்ளும் அந்த flag உள்ளதா என்று சரிபார்க்கவும்.

FAQ

எனது VPS-ல் /proc/cpuinfo கோப்பில் ஏன் aes flag இல்லை?

ஏனெனில், hypervisor ஒரு பொதுவான guest CPU மாதிரியையே காட்டுகிறது. qemu64 மற்றும் kvm64 ஆகியவற்றின் feature sets-ல் AES-NI இல்லை, எனவே இயற்பியல் ரீதியாக என்ன processor இருந்தாலும், CPUID அதை இல்லை என்றே காட்டும். வெவ்வேறு CPU-களைக் கொண்ட இயந்திரங்களுக்கு இடையில் இயங்கும் guest-ஐ மாற்ற முடியும் என்பதற்காகவே hosts இவ்வாறு செய்கின்றன. grep -m1 'model name' /proc/cpuinfo கட்டளையை இயக்கவும்: QEMU Virtual CPU version 2.5+ அல்லது Common KVM processor போன்ற ஒரு string இருந்தால் அதுவே காரணம். மாறாக, உண்மையான Xeon அல்லது EPYC மாதிரி பெயர் இருந்தால், CPU model அப்படியே கடத்தப்படுகிறது என்று அர்த்தம்; அப்போது அந்த flag உண்மையில் silicon-ல் இல்லை என்று பொருள்.

OPENSSL_ia32cap உண்மையில் AES-NI-ஐ செயல்படுத்துகிறதா அல்லது பாவனை செய்கிறதா?

இது உண்மையான instructions-ஐயே செயல்படுத்துகிறது. AES-NI instructions-க்கு சிறப்பு அனுமதி தேவையில்லை, hypervisor அவற்றை ஒருபோதும் தடுப்பதில்லை (trap), எனவே CPUID என்ன சொன்னாலும் AESENC நேரடியாகவே இயங்கும். CPUID instruction மட்டுமே இடைமறிக்கப்படுகிறது. OPENSSL_ia32cap-க்கு ஒரு plain hexadecimal மதிப்பை அமைப்பதன் மூலம், CPUID-யிடமிருந்து OpenSSL பெற்ற பதிலுக்குப் பதிலாக இந்த மதிப்பை அது பயன்படுத்தும். இதனால் OpenSSL அதன் hardware code path-ஐத் தேர்ந்தெடுக்கும், hardware அதை முழு வேகத்தில் இயக்கும். ஒருவேளை silicon-ல் அந்த instructions இல்லையென்றால், முதல் AES செயல்பாட்டின் போது process 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 மூலம் உண்மையான வேகத்தை அளந்து, அந்த flag-ஐக் காட்டும் host-உடன் aes-xts 256b வரிசையை ஒப்பிட்டுப் பார்க்கவும்.

AES-NI flag இல்லையென்றால் WireGuard வேகம் குறையுமா?

இல்லை. WireGuard அனைத்து தரவுக்கும் ChaCha20-Poly1305-ஐப் பயன்படுத்துகிறது, AES instructions-ஐப் பயன்படுத்துவதில்லை. எனவே, masked host மற்றும் unmasked host ஆகிய இரண்டிலும் அதன் throughput சமமாகவே இருக்கும். AES-GCM கொண்டு கட்டமைக்கப்பட்ட OpenVPN மற்றும் IPsec ஆகியவை AES-NI இல்லாத host-ல் வேகத்தை இழக்கும். எனவே, ஒரே VPS-ல் உள்ள இரண்டு tunnels வெவ்வேறு விதமாகச் செயல்படலாம்; network-ல் குறை என்று முடிவெடுக்கும் முன் இதைத் தெரிந்துகொள்வது அவசியம்.

ARM VPS-ல் AES-NI உள்ளதா என்பதை எப்படிச் சரிபார்ப்பது?

ARM cores-ல் AES-NI இருக்காது. அவற்றுக்கு ARMv8 cryptographic extensions உள்ளன, இவை வெவ்வேறு instructions மூலம் அதே வேலையைச் செய்கின்றன. 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-ல் வரையறுக்கப்பட்டுள்ளது.