VPS پر AES-NI چیک اور بحال کرنے کا طریقہ

VPS پر AES-NI حقیقت میں آپ کو کیا فائدہ دیتا ہے

VPS پر AES-NI، x86 کی چھ instructions کا مجموعہ ہے جو AES (advanced encryption standard) کے ایک round کو hardware میں انجام دیتی ہیں۔ اگر آپ کا provider CPU model میں ان instructions کو چھپا دے تو underlying silicon میں یہ پھر بھی موجود ہوتی ہیں، لیکن OpenSSL انہیں دیکھ نہیں سکتا اور software implementation پر واپس چلا جاتا ہے۔ اس implementation میں فی byte تقریباً دس گنا زیادہ cycles درکار ہوتے ہیں۔ آپ ایک command سے اس feature کی موجودگی چیک، دو commands سے فرق measure، اور اکثر ایک environment variable سے fast path دوبارہ فعال کر سکتے ہیں۔

یہ instructions AESENC، AESENCLAST، AESDEC، AESDECLAST، AESIMC اور AESKEYGENASSIST ہیں۔ Intel نے انہیں 2010 میں جاری کیا، اور AMD نے بھی اس کے بعد انہیں شامل کیا۔ اس لیے جس server CPU کو آپ عموماً rent کرتے ہیں، اس میں یہ silicon موجود ہوتا ہے۔ ایک معاون instruction، 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-based VPN traffic۔ AES-256-GCM کے ساتھ OpenVPN اور AES-GCM کے ساتھ IPsec، دونوں اس پر انحصار کرتے ہیں۔
• Encrypted backups۔ جو بھی سروس box سے باہر بھیجنے سے پہلے stream کو AES سے encrypt کرتی ہے، وہ یہی لاگت برداشت کرتی ہے۔

ایک عام workload پر اس کا کوئی اثر نہیں پڑتا۔ WireGuard اپنے data کے لیے ChaCha20-Poly1305 استعمال کرتا ہے اور AES کو بالکل نہیں چھیڑتا۔ اس لیے self-hosted WireGuard VPN، flag masked ہونے والے host پر بھی اسی رفتار سے چلتا ہے۔ سستے 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'

اگر دونوں میں سے کوئی بھی command aes پرنٹ کرے تو CPU اس guest کے لیے AES-NI ظاہر کرتا ہے۔ کچھ بھی پرنٹ نہ ہو تو AES-NI موجود نہیں ہے۔ lscpu بھی یہی flags پڑھتا ہے، اس لیے دونوں ہمیشہ ایک ہی نتیجہ دیتے ہیں۔ جو command installed ہو، وہ استعمال کریں۔

اب دیکھیں کہ 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 کا مطلب ہے کہ کچھ اور ہو رہا ہے، اور یہی صورت سمجھنے کے قابل ہے۔

جب silicon میں یہ موجود ہو تو flag کیوں غائب ہوتا ہے

CPUID وہ instruction ہے جسے program CPU کی supported خصوصیات معلوم کرنے کے لیے استعمال کرتا ہے۔ virtual machine کے اندر CPUID ہمیشہ hypervisor کو trap ہوتا ہے، اس لیے hypervisor فیصلہ کرتا ہے کہ guest کو کیا بتایا جائے۔ زیادہ تر panels اس فیصلے کو guest CPU model کے طور پر ظاہر کرتے ہیں۔ qemu64 اور kvm64 generic baseline models ہیں، اور دونوں کے feature set میں AES-NI یا SSSE3 شامل نہیں ہیں۔ اسی لیے physical host موجودہ EPYC ہونے کے باوجود guest کو aes flag نظر نہیں آتا۔ VPS کسی اور کے hardware پر چلنے والا guest ہے، اس لیے اس کی report کردہ ہر feature کا فیصلہ ایک سطح اوپر کیا جاتا ہے۔ اگر یہ layering آپ کے لیے نئی ہے تو پہلے VPS کیا ہے پڑھیں۔

Hosts جان بوجھ کر generic model منتخب کرتے ہیں، کیونکہ مختلف processors والی machines کے درمیان live migration اسی وقت کام کرتی ہے جب guest کو ایسی feature کے بارے میں کبھی نہ بتایا گیا ہو جو destination پر موجود نہ ہو۔ اس کا نقصان آپ کو ہوتا ہے۔ آپ کا kernel اور OpenSSL کی آپ کی copy دونوں startup کے وقت masked CPUID پڑھتے ہیں، اور پھر process کی پوری مدت کے لیے slow code path منتخب کرتے ہیں۔

اس مسئلے کا source پر حل host-side setting ہے: QEMU کی اصطلاح میں -cpu host، ایسا named model جس میں AES-NI شامل ہو، یا model میں شامل کیا گیا واضح +aes۔ آپ guest کے اندر سے ان میں سے کوئی setting تبدیل نہیں کر سکتے۔ Support ticket کھولنا، یا ایسا plan منتخب کرنا جس کا hypervisor CPU model کو pass through کرتا ہو، مستقل حل ہے۔

openssl speed سے فرق کی پیمائش کریں

شائع شدہ benchmark کو بلا تصدیق درست نہ مانیں۔ وہ cipher چلائیں جس پر آپ کا اپنا server حقیقت میں negotiation کرتا ہے۔

openssl version
openssl speed -evp aes-128-gcm

نتیجے کی row کو AES-128-GCM label کیا جاتا ہے اور یہ چھ block sizes پر throughput دیتی ہے، جس کی unit 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

یہ value OpenSSL کی اپنی capability vector documentation سے آتی ہے۔ شروع میں موجود ~ کا مطلب ہے کہ یہ bits صاف کریں۔ Bit 57 AES-NI ہے اور bit 33 PCLMULQDQ ہے، اس لیے 0x200000200000000 صرف انہی دو bits کی نشاندہی کرتا ہے۔ اگر دوسرا number پہلے سے بہت کم ہو تو آپ کے box میں AES-NI درست طور پر کام کر رہا ہے اور آپ کا کام مکمل ہے۔ اگر دونوں numbers یکساں ہوں تو 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
  }
]

یہ ایک modern x86 core کے لیے تقریباً 3.4 GHz پر شائع شدہ نمائندہ figures ہیں، نہ کہ کسی ایک host سے لی گئی measurement۔ انہیں ایک عمومی pattern کے طور پر دیکھیں۔ hardware path تقریباً 0.7 cycles per byte پر چلتا ہے، جبکہ software fallback تقریباً 11.0 cycles per byte پر، جو ایک core پر تقریباً 4,850 MB/s بمقابلہ 310 MB/s بنتا ہے۔ اوپر دی گئی دونوں commands ہی وہ واحد number دیتی ہیں جو آپ کے server کو بیان کرتا ہے۔ یہی اصول machine کے باقی حصوں پر بھی لاگو ہوتا ہے، اس لیے کسی plan کے بارے میں نتیجہ اخذ کرنے سے پہلے اسے VPS کو benchmark کرنے کے قابل تکرار طریقے کے ساتھ استعمال کریں۔

OPENSSL_ia32cap کے ذریعے bits کو دوبارہ فعال کریں

یہ وہ حصہ ہے جو لوگوں کو حیران کرتا ہے۔ AES-NI instructions کے لیے privileged access درکار نہیں ہوتا، اور hypervisor انہیں trap نہیں کرتا۔ صرف CPUID کو trap کیا جاتا ہے۔ اس لیے host آپ کے guest کو بتا سکتا ہے کہ AES-NI موجود نہیں، جبکہ AESENC بدستور native طور پر full speed پر execute ہوتا رہتا ہے۔ Software fast path چھوڑ دیتا ہے کیونکہ اس نے CPUID سے پوچھا اور اسے غلط جواب ملا۔ Instruction نے کام کرنا کبھی بند نہیں کیا۔

OpenSSL آپ کو CPU کی طرف سے جواب دینے دیتا ہے۔ OPENSSL_ia32cap میں plain 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 بھی ہے۔

یہاں دو warnings لاگو ہوتی ہیں، اور آپ دونوں کو جان بوجھ کر trigger کر سکتے ہیں۔

صرف پہلا vector set کرنے سے بعد کے vectors صفر رہتے ہیں، جس سے AVX2 اور AVX-512 code paths بند ہو جاتے ہیں۔ یہاں یہ جان بوجھ کر کیا گیا ہے۔ Masked guest پر AVX bits force کرنے کی کوشش نہ کریں، کیونکہ AVX registers کے لیے operating system کو XCR0 میں extended state enable کرنا ہوتا ہے، اور آپ کے kernel نے اسی masked CPUID کی بنیاد پر ایسا کرنے سے انکار کر دیا ہے۔ اس کے بعد VEX-encoded instruction undefined-opcode fault پیدا کرتی ہے اور process ختم ہو جاتا ہے۔

ایسے core پر AES-NI force کرنے سے، جس میں واقعی یہ سہولت موجود نہ ہو، process فوراً ختم ہو جاتا ہے:

Illegal instruction (core dumped)

یہ AESENC کے undefined-opcode fault پیدا کرنے کی وجہ سے ہوتا ہے، کیونکہ اس core پر execute کرنے کے لیے ایسی کوئی instruction موجود نہیں۔ کچھ server firmware اگلے reset تک hardware میں AES-NI کو disable بھی کر سکتے ہیں، اور symptom ایک جیسا ہوتا ہے۔ دونوں صورتوں میں حل مختلف environment variable نہیں بلکہ مختلف host ہے۔

کسی long-running 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 کھولتے ہوئے یہ نکتہ ثابت کرنا ہو۔

Override کیا درست نہیں کرتا

OPENSSL_ia32cap صرف OpenSSL تک پہنچتا ہے، کسی اور چیز تک نہیں۔ باقی تمام سافٹ ویئر اپنی feature detection چلاتے ہیں اور اس variable کو کبھی نہیں پڑھتے۔

Kernel اس کی اہم مثال ہے۔ dm-crypt اور LUKS، kernel crypto API استعمال کرتے ہیں، اور aesni_intel module اس وقت load ہونے سے انکار کر دیتا ہے جب CPU feature bit موجود نہ ہو:

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

اس کے لیے user-space variable موجود نہیں ہے۔ Kernel boot کے وقت CPUID کو ایک بار پڑھتا ہے، اور یہ فیصلہ اس وقت تک برقرار رہتا ہے جب تک آپ کسی مختلف host پر reboot نہ کریں۔ اس لیے آپ کا encrypted volume software cipher استعمال کرتا رہے گا، چاہے OpenSSL کچھ بھی کر رہا ہو۔ جو کارکردگی آپ کو حقیقت میں مل رہی ہے، اسے ناپیں:

sudo cryptsetup benchmark -c aes-xts -s 256

aes-xts 256b row hardware AES کے ساتھ ہزاروں MiB/s تک پہنچتی ہے، جبکہ hardware AES کے بغیر نچلے سینکڑوں MiB/s تک رہتی ہے۔ اپنی detection رکھنے والے language runtimes بھی اسی طرح اس override سے متاثر نہیں ہوتے؛ ان میں Go اور Java شامل ہیں۔ Go کا crypto/aes براہ راست CPUID چیک کرتا ہے اور bit clear ہونے پر خاموشی سے اپنی constant-time software implementation استعمال کرتا ہے۔ اگر آپ کی TLS terminate کرنے والی service Go binary ہے، تو OpenSSL variable اس کے لیے کچھ بھی تبدیل نہیں کرتا۔

اگر 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 میں TLS 1.3 کے لیے کوئی dedicated directive نہیں ہے اور وہ اس string کو بغیر جانچ کے براہِ راست OpenSSL کو بھیجتا ہے۔ اس لیے وہاں typo خاموشی سے قبول ہو جاتا ہے۔ 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 میں ARMv8 cryptographic extensions استعمال ہوتی ہیں، جو اسی کام کے لیے الگ instruction set فراہم کرتی ہیں۔ 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 میں موجود نہیں ہے، اور زبردستی چلایا گیا run بہت تیز ہے۔ Host، CPUID کو mask کر رہا ہے۔ تصدیق کریں کہ model name generic ہے، پھر اپنے provider سے پوچھیں کہ اس کا hypervisor guest کو کون سا CPU model فراہم کرتا ہے۔

aes، /proc/cpuinfo میں موجود نہیں ہے، اور زبردستی چلایا گیا run Illegal instruction دکھاتا ہے۔ یہ instructions واقعی موجود نہیں ہیں، یا firmware نے انہیں disabled کر رکھا ہے۔ Workload کو کسی دوسرے host پر منتقل کریں۔

aes موجود ہے، لیکن throughput اب بھی کم ہے۔ تصدیق کریں کہ آپ 8192-byte column پڑھ رہے ہیں اور کوئی دوسری چیز core استعمال نہیں کر رہی۔ Shared plan میں noisy neighbour عین اسی طرح نظر آتا ہے جیسے CPU feature موجود نہ ہو، جب تک آپ دن کے مختلف اوقات میں test دو مرتبہ نہ چلائیں۔

Masked run اور normal run ایک ہی number دیتے ہیں۔ OpenSSL پہلے ہی software path پر چل رہا تھا۔ یہی نتیجہ اصل finding ہے، test کی غلطی نہیں۔

Nested virtualisation ایک سطح نیچے جواب بدل دیتی ہے۔ Guest کے اندر موجود guest کو وہی CPUID ملتا ہے جسے درمیانی layer آگے بھیجنے کا انتخاب کرتی ہے، اور وہاں AES-NI کا غائب ہو جانا باآسانی نظر انداز ہو سکتا ہے۔ اگر آپ VPS پر nested virtual machines چلا رہے ہیں تو rented machine کے ساتھ ساتھ inner guest کے اندر بھی flag چیک کریں۔

FAQ

میرے VPS میں /proc/cpuinfo میں aes flag کیوں موجود نہیں؟

کیونکہ hypervisor generic guest CPU model پیش کر رہا ہے۔ qemu64 اور kvm64 کے feature sets میں AES-NI شامل نہیں، اس لیے CPUID اسے غائب رپورٹ کرتا ہے، خواہ physical processor کوئی بھی ہو۔ Hosts ایسا اس لیے کرتے ہیں تاکہ running guest کو مختلف CPUs والی مشینوں کے درمیان 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 instructions unprivileged ہوتی ہیں اور hypervisor انہیں کبھی trap نہیں کرتا، اس لیے AESENC، CPUID کی رپورٹ سے قطع نظر، 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 پڑھتا ہے، اور کوئی دوسرا component نہیں۔ 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 اسے تبدیل نہیں کر سکتا۔ اصل figure sudo cryptsetup benchmark -c aes-xts -s 256 سے measure کریں اور aes-xts 256b row کا موازنہ ایسے host سے کریں جو flag report کرتا ہو۔

کیا AES-NI flag نہ ہونے سے WireGuard سست ہو جاتا ہے؟

نہیں۔ WireGuard تمام data کے لیے ChaCha20-Poly1305 استعمال کرتا ہے اور AES instructions کبھی استعمال نہیں کرتا، اس لیے masked host اور unmasked host پر اس کا throughput یکساں رہتا ہے۔ AES-GCM کے ساتھ configured OpenVPN اور IPsec، AES-NI کے بغیر host پر throughput کھو دیتے ہیں۔ اس لیے ایک ہی VPS پر دو tunnels کا رویہ بہت مختلف ہو سکتا ہے۔ Network کو ذمہ دار ٹھہرانے سے پہلے یہ بات جاننا مفید ہے۔

ARM VPS پر AES-NI کی موجودگی کیسے check کروں؟

ARM cores میں AES-NI نہیں ہوتا۔ ان میں ARMv8 cryptographic extensions ہوتے ہیں، جو مختلف instructions کے ذریعے یہی کام کرتے ہیں۔ grep -m1 Features /proc/cpuinfo چلائیں اور aes اور pmull تلاش کریں، کیونکہ aarch64 انہیں flags کے بجائے Features کے تحت list کرتا ہے۔ x86 OPENSSL_ia32cap value کا ARM پر کوئی مطلب نہیں۔ وہاں OpenSSL کا equivalent variable OPENSSL_armcap ہے، اور اس کا bit layout OpenSSL source میں crypto/arm_arch.h میں defined ہے۔