OpenSSL இல் AES-NI அல்லது கர்னல் ஆஃப்லோட்: எது தேவை?

இரண்டு லேபிள்கள் ஒரே விஷயம் போலப் பயன்படுத்தப்படுகின்றன: வன்பொருளால் முடுக்கப்பட்டது மற்றும் கர்னலுக்கு மாற்றப்பட்டது. ஒன்று ஒரு நூலகத்தின் AES வழக்கமானது எந்தக் கட்டளைகளை இயக்குகிறது என்பதை விவரிக்கிறது, மற்றது பாக்கெட் செயலாக்கம் எங்கு நடக்கிறது என்பதை விவரிக்கிறது. VPN முதல் ஒன்றை இரண்டாவது இல்லாமல், இரண்டாவது முதல் இல்லாமல், அல்லது இரண்டையும் சேர்த்து வைத்திருக்கலாம். செயல்திறன் பற்றிய எந்த முடிவும் நீங்கள் உண்மையில் இவை இரண்டில் எதை மாற்றுகிறீர்கள் என்று பெயரிடுவதில் தொடங்க வேண்டும்.

இரண்டு அச்சுகள், ஒரு மதிப்பெண் அல்ல

முதல் அச்சு செயலாக்கம்: AES-256-GCM செய்யும் குறியீடு செயலியின் பிரத்யேக கட்டளைகளைப் பயன்படுத்தும் பதிப்புக்குச் செல்கிறதா அல்லது அவற்றை சாதாரண கணக்கீடாக இயக்கும் இடமாற்றக்கூடிய வழக்கத்திற்குச் செல்கிறதா. இந்தத் தேர்வு கிரிப்டோகிராஃபிக் நூலகத்தின் உள்ளே வாழ்கிறது மற்றும் அது தொடங்கும் போது எடுக்கப்படுகிறது.

இரண்டாவது அச்சு இடம்: பாக்கெட் கர்னலின் மாற்றப் பாதையைக் கடக்கிறதா அல்லது பயனர் இடத்தில் உள்ள டீமன் சுரங்கப் பாதைச் சாதனத்திலிருந்து படித்து, மறையாக்கி, மீண்டும் எழுதுகிறதா.

எந்த அச்சும் மற்றொன்றைக் கட்டுப்படுத்தவில்லை. AES கட்டளைகள் உள்ள CPU இல் பயனர் இடத்து VPN அவற்றை எப்போதும் பயன்படுத்தலாம், அவை இல்லாத CPU இல் கர்னல் பாதை மென்பொருள் செயலாக்கத்திற்குத் திரும்புகிறது. விற்பனையாளர் ஆவணங்களில் உள்ள லேபிள்கள் இந்த வேறுபாட்டை அரிதாகவே காட்டுகின்றன, அதனால்தான் இரண்டு சூழ்நிலைகளுக்கு இடையே நகலெடுக்கப்பட்ட சரிசெய்தல் ஆலோசனைகள் பல நேரங்களில் எதுவும் செய்யவில்லை.

அச்சு ஒன்று: எந்தக் குறியீடு மறையாக்கம் செய்கிறது

OpenSSL தொடக்கத்தின் போது செயலியின் அம்சங்களைக் கண்டறிந்து மேம்படுத்தப்பட்ட குறியீட்டுப் பாதைகளைத் தேர்ந்தெடுக்க முடிவைப் பயன்படுத்துகிறது, x86 திறன்கள் பற்றிய ஆவணம் விவரிப்பது போல. AES-NI அந்த அனுப்புதலுக்குப் பின்னால் உள்ள ஆவணப்படுத்தப்பட்ட திறன்களில் ஒன்றாகும். இவற்றில் எதுவும் நூலகம் கர்னல் கூறாக மாற வேண்டும் என்று கோரவில்லை.

விரைவான பாதை பயன்படுத்தப்படுகிறது என்று கருதுவதற்கு முன் அம்சம் செயல்முறைக்குத் தெரிகிறதா என்பதை உறுதிப்படுத்தவும். Linux இல் மூலம் /proc/cpuinfo இல் உள்ள flags புலம், மேலும் விருந்தினருக்குள் அது ஹைப்பர்வைசர் வெளிப்படுத்துவதைப் பிரதிபலிக்கிறது, இயற்பியல் ஹோஸ்டின் மாடல் பெயரை அல்ல.

grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verbose

இரண்டாவது கட்டளை அந்த பில்டில் ஏற்றப்பட்ட வழங்குநர்களைப் பெயரிடுகிறது. VPN சேவை எந்த நூலகத்தை இணைத்தது என்று அது சொல்லாது, ஒரு ஹோஸ்ட் இரண்டு OpenSSL நிறுவல்களைக் கொண்டிருக்கலாம், ஆனால் இயங்கும் செயல்முறை அவற்றில் ஒன்றை மட்டுமே பயன்படுத்துகிறது.

அச்சு இரண்டு: பாக்கெட் பாதை எங்கு இயங்குகிறது

கர்னலில் வைப்பது என்பது மாற்றம் கர்னலின் சொந்த IPsec இயந்திரத்தில் அல்லது கர்னலுக்குள் உள்ள சுரங்கப்பாதை இயக்கியில் நடக்கிறது, எனவே ஒவ்வொரு தொகுப்பிற்கும் பாக்கெட்டுகள் பயனர் இடத்து செயல்முறை வழியாகச் சென்று வர வேண்டியதில்லை. இது நகல்களையும் சூழல் மாற்றங்களையும் குறைக்கலாம், மேலும் ஒற்றை இழை டீமனால் முடியாத வகையில் வேலையை கோர்களுக்கு பரப்பலாம். நீங்கள் கட்டுப்படுத்தாத எல்லையின் மறுபக்கத்தில் வேலை இப்போது நடப்பதால், செயல்திறன் வீழும்போது நீங்கள் படிக்கும் கவுண்டர்களையும் தடயங்களையும் அது நகர்த்துகிறது. இதை செயல்திறன் முடிவாக மட்டுமல்ல, பிழைதிருத்தச் செலவாகக் கருதுங்கள்.

இது கட்டளை ஆதரவை உருவாக்காது, சைஃபரை உள்ளமைக்காது, இருக்கும் பாதையை வேலை செய்யவைக்காது.

மெய்நிகராக்கம் இந்த அச்சிலும் ஒரு மடிப்பைச் சேர்க்கிறது. விருந்தினருக்கு ஹோஸ்டிடம் உள்ள அம்சங்களை மறைக்கும் முகமூடி CPU மாதிரி வழங்கப்படலாம், உள்ளே உள்ள விருந்தினர் இன்னும் குறைவாகக் காணலாம். திறன் காட்சியை VPN உண்மையில் இயங்கும் சூழலின் உள்ளிருந்து படியுங்கள், ஹைப்பர்வைசர் பணியகத்திலிருந்து அல்ல.

ஒவ்வொரு தேர்வும் என்ன வாங்குகிறது, என்ன செய்ய முடியாது

நடைமுறைக் கேள்வி நேரம் எங்கு செல்கிறது என்பதுதான். ஒரு பிஸியான இழை, திரும்பத் திரும்ப வரும் இடையக நகல்கள் அல்லது ஒவ்வொரு பாக்கெட்டுக்கும் ஒரு கணினி அழைப்பு செயல்திறனைக் கட்டுப்படுத்தினால், அந்தச் செலவுகளை நீக்கும் பாதைக்கு மாற்றத்தை நகர்த்துவது உதவலாம், கர்னல் தேவையான மாற்றத்தைச் செயல்படுத்தினால்.

வரம்பு நெரிசலான மேல்நோக்கு இணைப்பு, இழப்புள்ள பாதை, நீண்ட சென்று வரும் நேரம், நிரம்பிய இலக்குச் சேவை அல்லது ஒரு கோரில் பொருத்தப்பட்ட ஒரு இழை என்றால், இடம் முக்கியமான எதையும் மாற்றாது. கட்டளைத் தேர்வுக்கும் இதுவே பொருந்தும்: பிரத்யேக வன்பொருளில் AES காணாமல் போன பாதையைச் சரிசெய்ய முடியாது, பெயர் தீர்வு தோல்வியடைந்ததால் சுரங்கப்பாதை செயலற்றிருந்தால் உதவாது.

இரண்டும் பொருந்தும் இடத்தில் அவை இணைகின்றன. கர்னல் பாதை கர்னலின் கிரிப்டோ APIக்குள் அதே கட்டளை அளவிலான அனுப்புதலைப் பயன்படுத்தலாம், நன்கு தேர்ந்தெடுக்கப்பட்ட நூலகத்துடன் கூடிய பயனர் இடத்து பாதை ஏற்கனவே அதைப் பயன்படுத்துகிறது. முடிவு என்பது சுருக்கமாக எது வேகமானது என்பதல்ல; எந்தச் செலவுக்கு உங்களிடம் சான்று உள்ளது என்பதுதான்.

எதையும் மாற்றுவதற்கு முன் நான்கு உண்மைகளை எழுதுங்கள்

சேவையின் இரும மற்றும் அது இணைக்கப்பட்ட கிரிப்டோ நூலகத்தை எழுதுங்கள், ஏனெனில் அவை முதல் அச்சைத் தீர்மானிக்கின்றன. பின்னர் ஒப்புக்கொள்ளப்பட்ட தரவுப் பாதுகாப்பைப் பதிவு செய்யுங்கள், ஏனெனில் பிரத்யேக கட்டளைப் பாதை இல்லாத சைஃபர் அதைக் கொண்டிருப்பதை விட வேறுவிதமாக நடந்துகொள்கிறது, மேலும் தொகுப்பை இரு தரப்பும் தேர்ந்தெடுக்கின்றன.

பின்னர், இயங்கும் சூழலின் உள்ளிருந்து திறன் காட்சி, இறுதியாக நீங்கள் இயக்கப்பட்டதாக நினைக்கும் பயன்முறை உண்மையில் அப்படியே உள்ளது என்பதற்கான சான்றுடன் செயலில் உள்ள பாக்கெட் பாதை. ஏற்றப்பட்ட தொகுதி ஒரு சுயவிவரம் அதைப் பயன்படுத்துகிறது என்பதற்கான சான்று அல்ல, உள்ளமைவு வரி கர்னல் அதை ஏற்றுக்கொண்டது என்பதற்கான சான்று அல்ல.

ஒரு விஷயத்தை மாற்றி, பின்னர் அதே முனைப் புள்ளிகள் மற்றும் அதே பரிமாற்றத் திசையுடன் கூடிய நிலையான பணிச்சுமையுடன் ஒப்பிடுங்கள். நீங்கள் அளவிடாத வேகக் கூற்று, பின்தளம் ஒருபோதும் சந்தேகத்தில் இல்லை என்ற குறிப்பை விடக் குறைவான மதிப்புடையது.