முன்னாள் kernel.org CSO மற்றும் உபுண்டு பாதுகாப்புக் குழுவின் தலைவர் கீஸ் குக், இப்போது ஆண்ட்ராய்டு மற்றும் ChromeOS ஐப் பாதுகாக்க Google இல் பணிபுரிகிறார், கர்னலின் நிலையான கிளைகளில் பிழைகளை சரிசெய்யும் தற்போதைய செயல்முறை குறித்து கவலை தெரிவித்தார். ஒவ்வொரு வாரமும், சுமார் நூறு திருத்தங்கள் நிலையான கிளைகளில் சேர்க்கப்படுகின்றன, மேலும் அடுத்த வெளியீட்டிற்கான மாற்றங்களை ஏற்றுக்கொள்வதற்கான சாளரத்தை மூடிய பிறகு, அது ஆயிரத்தை நெருங்குகிறது (பராமரிப்பாளர்கள் சாளரம் மூடப்படும் வரை திருத்தங்களை வைத்திருக்கிறார்கள், மேலும் "-rc1" உருவான பிறகு அவர்கள் திரட்டப்பட்டவற்றை ஒரே நேரத்தில் வெளியிடவும்), இது மிகவும் அதிகமாக உள்ளது மற்றும் லினக்ஸ் கர்னலை அடிப்படையாகக் கொண்ட பராமரிப்பு தயாரிப்புகளுக்கு அதிக உழைப்பு தேவைப்படுகிறது.
கீஸின் கூற்றுப்படி, கர்னலில் உள்ள பிழைகளுடன் பணிபுரியும் செயல்முறை சரியான கவனம் செலுத்தப்படவில்லை மற்றும் இந்த பகுதியில் ஒருங்கிணைந்த வேலைக்காக கர்னலில் குறைந்தது 100 கூடுதல் டெவலப்பர்கள் இல்லை. கோர் கர்னல் டெவலப்பர்கள் வழக்கமான அடிப்படையில் பிழைகளை சரிசெய்கிறார்கள், ஆனால் இந்த திருத்தங்கள் மூன்றாம் தரப்பினரால் பயன்படுத்தப்படும் கர்னல் மாறுபாடுகளுக்கு அனுப்பப்படும் என்பதற்கு எந்த உத்தரவாதமும் இல்லை. Linux கர்னலை அடிப்படையாகக் கொண்ட பல்வேறு தயாரிப்புகளின் பயனர்கள் தங்கள் சாதனங்களில் எந்த பிழைகள் சரி செய்யப்படுகின்றன மற்றும் எந்த கர்னல் பயன்படுத்தப்படுகின்றன என்பதைக் கட்டுப்படுத்த வழி இல்லை. விற்பனையாளர்கள் தங்கள் தயாரிப்புகளின் பாதுகாப்பிற்கு இறுதியில் பொறுப்பாவார்கள், ஆனால் நிலையான கர்னல் கிளைகளில் மிக அதிக ஒட்டுதல் விகிதத்துடன், அனைத்து இணைப்புகளையும் பேக்போர்ட் செய்வது, மிக முக்கியமானவற்றைத் தேர்ந்தெடுத்து போர்ட் செய்வது அல்லது அனைத்து இணைப்புகளையும் புறக்கணிப்பது ஆகியவற்றுக்கு இடையேயான தேர்வை எதிர்கொண்டனர்.
மிக முக்கியமான திருத்தங்கள் மற்றும் பாதிப்புகளை மட்டும் மாற்றுவதே சிறந்த தீர்வாக இருக்கும், ஆனால் பொதுவான ஓட்டத்தில் இருந்து இத்தகைய பிழைகளை தனிமைப்படுத்துவது முக்கிய பிரச்சனையாகும். பாப்-அப் செய்யும் பெரும்பாலான சிக்கல்கள் சி மொழியைப் பயன்படுத்துவதால் ஏற்படுகின்றன, நினைவகம் மற்றும் சுட்டிகளைக் கையாளும் போது மிகுந்த கவனம் தேவை. விஷயங்களை மோசமாக்க, பல சாத்தியமான பாதிப்புத் திருத்தங்கள் CVE அடையாளங்காட்டிகளுடன் வழங்கப்படவில்லை அல்லது பேட்ச் வெளியிடப்பட்ட சிறிது நேரத்திற்குப் பிறகு அத்தகைய அடையாளங்காட்டியைப் பெறலாம். இத்தகைய நிலைமைகளின் கீழ், பெரிய பாதுகாப்பு சிக்கல்களில் இருந்து சிறிய திருத்தங்களை பிரிப்பது உற்பத்தியாளர்களுக்கு மிகவும் கடினம். புள்ளிவிபரங்களின்படி, CVE ஒதுக்கப்படுவதற்கு முன்பே 40%க்கும் அதிகமான பாதிப்புகள் சரி செய்யப்படுகின்றன, மேலும் ஒரு பேட்சை வெளியிடுவதற்கும் CVE-ஐ ஒதுக்குவதற்கும் இடையே சராசரி தாமதம் மூன்று மாதங்கள் (அதாவது, முதலில், பேட்ச் பொதுவானதாகக் கருதப்படுகிறது. பிழை, ஆனால் சில மாதங்களுக்குப் பிறகுதான் பாதிப்பு சரி செய்யப்பட்டது என்பது தெளிவாகிறது).
இதன் விளைவாக, பாதிப்புகளுக்கான தீர்வுகளுடன் ஒரு தனி கிளை இல்லாமல் மற்றும் ஒரு குறிப்பிட்ட சிக்கலின் பாதுகாப்பு இணைப்பு பற்றிய தகவலைப் பெறாமல், Linux கர்னலை அடிப்படையாகக் கொண்ட தயாரிப்புகளின் உற்பத்தியாளர்கள் புதிய நிலையான கிளைகளில் இருந்து அனைத்து திருத்தங்களையும் தொடர்ந்து மாற்றுவதற்கு விடப்படுகிறார்கள். ஆனால் இந்த வேலைக்கு நிறைய உழைப்பு தேவைப்படுகிறது மற்றும் உற்பத்தியின் இயல்பான செயல்பாட்டை சீர்குலைக்கும் பிற்போக்கு மாற்றங்களின் பயம் காரணமாக நிறுவனங்களில் எதிர்ப்பை எதிர்கொள்கிறது.
லினஸ் டொர்வால்ட்ஸின் கூற்றுப்படி, அனைத்து பிழைகளும் முக்கியமானவை மற்றும் பாதிப்புகள் மற்ற வகை பிழைகளிலிருந்து பிரிக்கப்படக்கூடாது மற்றும் தனி உயர் முன்னுரிமை வகைக்கு ஒதுக்கப்படக்கூடாது என்பதை நினைவில் கொள்க. பாதுகாப்புச் சிக்கல்களில் நிபுணத்துவம் பெறாத ஒரு சாதாரண டெவலப்பருக்கு, பிழைத்திருத்தத்திற்கும் சாத்தியமான பாதிப்புக்கும் இடையே உள்ள தொடர்பு வெளிப்படையாகத் தெரியவில்லை (பல திருத்தங்களுக்கு, அவை பாதுகாப்புடன் தொடர்புடையவை என்பதைத் தனியான தணிக்கை மட்டுமே உங்களை அனுமதிக்கிறது. ) லினஸின் கூற்றுப்படி, லினக்ஸ் விநியோகங்களில் கர்னல் தொகுப்புகளைப் பராமரிப்பதற்குப் பொறுப்பான குழுக்களில் உள்ள பாதுகாப்புக் குழுக்கள் பொது இணைப்பு ஓட்டத்திலிருந்து சாத்தியமான பாதிப்புகளைத் தனிமைப்படுத்த வேண்டும்.
கர்னலை நியாயமான நீண்ட காலச் செலவில் பாதுகாப்பாக வைத்திருப்பதற்கான ஒரே தீர்வு, அப்ஸ்ட்ரீம் கர்னலில் உள்ள பேட்ச்கள் மற்றும் பாதிப்புகளைப் பராமரிக்க, லோக்கல் கர்னல் கட்டுமானங்களுக்கு போர்ட்டிங் பேட்ச்களில் ஈடுபட்டுள்ள பொறியாளர்களை நிறுவனங்கள் நகர்த்துவதுதான் என்று கீஸ் குக் நம்புகிறார். அதன் தற்போதைய வடிவத்தில், பல உற்பத்தியாளர்கள் தங்கள் தயாரிப்புகளில் சமீபத்திய கர்னல் பதிப்பைப் பயன்படுத்துவதில்லை மற்றும் பேக்போர்ட் திருத்தங்களைத் தாங்களாகவே பயன்படுத்துகின்றனர், அதாவது. வெவ்வேறு நிறுவனங்களில் உள்ள பொறியாளர்கள் ஒருவருக்கொருவர் வேலையை நகலெடுத்து, அதே சிக்கலைத் தீர்க்கிறார்கள்.
எடுத்துக்காட்டாக, 10 நிறுவனங்கள், ஒவ்வொன்றும் ஒரே மாதிரியான திருத்தங்களை ஆதரிக்கும் ஒரு பொறியாளரைக் கொண்டு, அந்த பொறியாளர்களை அப்ஸ்ட்ரீமில் பிழைகளைச் சரிசெய்வதற்குத் திருப்பியனுப்பினால், ஒரு திருத்தத்தை அனுப்புவதற்குப் பதிலாக, பொதுவான நன்மைக்காக 10 வெவ்வேறு பிழைகளைச் சரிசெய்யலாம் அல்லது முன்மொழியப்பட்ட மாற்றங்களின் மதிப்பாய்வில் சேரலாம். கர்னலில் தரமற்ற குறியீடு சேர்க்கப்படுவதைத் தடுக்கவும். சோதனை மற்றும் குறியீடு பகுப்பாய்விற்கான புதிய கருவிகளை உருவாக்குவதற்கும் வளங்கள் அர்ப்பணிக்கப்படலாம், இது ஆரம்ப கட்டத்தில் மீண்டும் மீண்டும் தோன்றும் வழக்கமான வகை பிழைகளை தானாகவே அடையாளம் காண அனுமதிக்கும்.
கீஸ் குக், முக்கிய மேம்பாட்டு செயல்பாட்டில் நேரடியாக தானியங்கு மற்றும் தெளிவற்ற சோதனைகளை மிகவும் செயலில் பயன்படுத்த பரிந்துரைக்கிறார், தொடர்ச்சியான ஒருங்கிணைப்பு அமைப்புகளின் பயன்பாடு மற்றும் மின்னஞ்சல் வழியாக தொன்மையான மேம்பாட்டு நிர்வாகத்தை கைவிடுதல். தற்போது, முக்கிய சோதனை செயல்முறைகள் வளர்ச்சியிலிருந்து பிரிக்கப்பட்டு வெளியீடுகள் உருவான பிறகு நிகழும் உண்மையால் பயனுள்ள சோதனை தடைபட்டுள்ளது. பிழைகளைக் குறைக்க ரஸ்ட் போன்ற மிகவும் பாதுகாப்பான மொழிகளைப் பயன்படுத்தவும் விசைகள் பரிந்துரைக்கப்படுகின்றன.
ஆதாரம்: opennet.ru