Linux కెర్నల్‌లోని లోపాలపై పని చేసే ప్రక్రియను ఆధునికీకరించాలని Google యొక్క కీస్ కుక్ కోరారు

కీస్ కుక్, మాజీ kernel.org CSO మరియు ఉబుంటు సెక్యూరిటీ టీమ్ నాయకుడు, ఇప్పుడు ఆండ్రాయిడ్ మరియు ChromeOSలను సురక్షితంగా ఉంచడానికి Google కోసం పనిచేస్తున్నారు, కెర్నల్ యొక్క స్థిరమైన శాఖలలో బగ్‌లను పరిష్కరించే ప్రస్తుత ప్రక్రియ గురించి ఆందోళన వ్యక్తం చేశారు. ప్రతి వారం, దాదాపు వంద పరిష్కారాలు స్థిరమైన శాఖలలో చేర్చబడతాయి మరియు తదుపరి విడుదలకు మార్పులను అంగీకరించడానికి విండోను మూసివేసిన తర్వాత, అది వెయ్యికి చేరుకుంటుంది (విండో మూసివేయబడే వరకు నిర్వహణదారులు పరిష్కారాలను కలిగి ఉంటారు మరియు “-rc1” ఏర్పడిన తర్వాత వారు సేకరించిన వాటిని ఒకేసారి ప్రచురించండి), ఇది చాలా ఎక్కువ మరియు Linux కెర్నల్ ఆధారంగా నిర్వహణ ఉత్పత్తులకు చాలా శ్రమ అవసరం.

కీస్ ప్రకారం, కెర్నల్‌లోని లోపాలతో పని చేసే ప్రక్రియకు తగిన శ్రద్ధ ఇవ్వబడదు మరియు ఈ ప్రాంతంలో సమన్వయ పని కోసం కెర్నల్‌లో కనీసం 100 అదనపు డెవలపర్‌లు లేవు. కోర్ కెర్నల్ డెవలపర్లు క్రమ పద్ధతిలో బగ్‌లను పరిష్కరిస్తారు, అయితే ఈ పరిష్కారాలు థర్డ్ పార్టీలు ఉపయోగించే కెర్నల్ వేరియంట్‌లకు పోర్ట్ చేయబడతాయని ఎటువంటి హామీ లేదు. Linux కెర్నల్‌పై ఆధారపడిన వివిధ ఉత్పత్తుల వినియోగదారులకు ఏ బగ్‌లు పరిష్కరించబడ్డాయి మరియు వారి పరికరాల్లో ఏ కెర్నల్ ఉపయోగించబడుతుందో నియంత్రించడానికి మార్గం లేదు. విక్రేతలు తమ ఉత్పత్తుల భద్రతకు అంతిమంగా బాధ్యత వహిస్తారు, కానీ స్థిరమైన కెర్నల్ బ్రాంచ్‌లలో చాలా ఎక్కువ ప్యాచింగ్ రేట్‌తో, వారు అన్ని ప్యాచ్‌లను బ్యాక్‌పోర్ట్ చేయడం, అత్యంత ముఖ్యమైన వాటిని పోర్ట్ చేయడం లేదా అన్ని ప్యాచ్‌లను విస్మరించడం మధ్య ఎంపికను ఎదుర్కొన్నారు.

Linux కెర్నల్‌లోని లోపాలపై పని చేసే ప్రక్రియను ఆధునికీకరించాలని Google యొక్క కీస్ కుక్ కోరారు

అత్యంత ముఖ్యమైన పరిష్కారాలు మరియు దుర్బలత్వాలను మాత్రమే తరలించడం సరైన పరిష్కారం, అయితే సాధారణ ప్రవాహం నుండి అటువంటి లోపాలను వేరు చేయడం ప్రధాన సమస్య. మెమరీ మరియు పాయింటర్‌లతో వ్యవహరించేటప్పుడు చాలా జాగ్రత్తలు అవసరమయ్యే సి లాంగ్వేజ్‌ని ఉపయోగించడం వల్ల చాలా సమస్యలు తలెత్తుతాయి. విషయాలను మరింత దిగజార్చడానికి, అనేక సంభావ్య దుర్బలత్వ పరిష్కారాలు CVE ఐడెంటిఫైయర్‌లతో అందించబడవు లేదా ప్యాచ్ ప్రచురించబడిన కొంత సమయం తర్వాత అటువంటి ఐడెంటిఫైయర్‌ను స్వీకరించండి. అటువంటి పరిస్థితులలో, ప్రధాన భద్రతా సమస్యల నుండి చిన్న పరిష్కారాలను వేరు చేయడం తయారీదారులకు చాలా కష్టం. గణాంకాల ప్రకారం, CVE కేటాయించబడటానికి ముందు 40% కంటే ఎక్కువ దుర్బలత్వాలు పరిష్కరించబడతాయి మరియు పరిష్కారాన్ని విడుదల చేయడం మరియు CVE యొక్క కేటాయింపు మధ్య సగటు ఆలస్యం మూడు నెలలు (అనగా, మొదటగా, పరిష్కారాన్ని గుర్తించడం జరిగింది ఒక సాధారణ బగ్, కానీ కొన్ని నెలల తర్వాత మాత్రమే దుర్బలత్వం పరిష్కరించబడిందని స్పష్టమవుతుంది).

ఫలితంగా, దుర్బలత్వాలకు పరిష్కారాలతో ప్రత్యేక శాఖ లేకుండా మరియు నిర్దిష్ట సమస్య యొక్క భద్రతా కనెక్షన్ గురించి సమాచారాన్ని పొందకుండా, Linux కెర్నల్ ఆధారంగా ఉత్పత్తుల తయారీదారులు తాజా స్థిరమైన శాఖల నుండి అన్ని పరిష్కారాలను నిరంతరం బదిలీ చేయడానికి మిగిలిపోతారు. కానీ ఈ పనికి చాలా శ్రమ అవసరం మరియు ఉత్పత్తి యొక్క సాధారణ ఆపరేషన్‌కు అంతరాయం కలిగించే తిరోగమన మార్పుల భయం కారణంగా కంపెనీలలో ప్రతిఘటనను ఎదుర్కొంటుంది.

లైనస్ టోర్వాల్డ్స్ ప్రకారం, అన్ని లోపాలు ముఖ్యమైనవి మరియు బలహీనతలను ఇతర రకాల లోపాల నుండి వేరు చేయకూడదు మరియు ప్రత్యేక అధిక ప్రాధాన్యత గల వర్గానికి కేటాయించకూడదు. భద్రతా సమస్యలలో నైపుణ్యం లేని సాధారణ డెవలపర్‌కు, పరిష్కారానికి మరియు సంభావ్య దుర్బలత్వానికి మధ్య కనెక్షన్ స్పష్టంగా ఉండదు (అనేక పరిష్కారాల కోసం, ప్రత్యేక ఆడిట్ మాత్రమే అవి భద్రతకు సంబంధించినవని అర్థం చేసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. ) Linus ప్రకారం, సాధారణ ప్యాచ్ ప్రవాహం నుండి సంభావ్య దుర్బలత్వాలను వేరు చేయడానికి Linux పంపిణీలపై కెర్నల్ ప్యాకేజీలను నిర్వహించడం బాధ్యత వహించే టీమ్‌లలోని భద్రతా బృందాలు.

అప్‌స్ట్రీమ్ కెర్నల్‌లో ప్యాచ్‌లు మరియు దుర్బలత్వాలను నిర్వహించడానికి సహకారంతో మరియు సమన్వయంతో పనిచేయడానికి కంపెనీలు పోర్టింగ్ ప్యాచ్‌లలో పాల్గొన్న ఇంజనీర్‌లను స్థానిక కెర్నల్ బిల్డ్‌లకు తరలించడమే కెర్నల్‌ను సహేతుకమైన దీర్ఘకాలిక ఖర్చుతో సురక్షితంగా ఉంచడానికి ఏకైక పరిష్కారం అని కీస్ కుక్ అభిప్రాయపడ్డారు. దాని ప్రస్తుత రూపంలో, చాలా మంది తయారీదారులు తమ ఉత్పత్తులలో తాజా కెర్నల్ సంస్కరణను ఉపయోగించరు మరియు వారి స్వంత బ్యాక్‌పోర్ట్ పరిష్కారాలను ఉపయోగించరు, అనగా. వేర్వేరు కంపెనీల్లోని ఇంజనీర్లు ఒకరి పనిని మరొకరు నకిలీ చేసి, అదే సమస్యను పరిష్కరిస్తారు.

ఉదాహరణకు, 10 కంపెనీలు, ఒక్కో ఇంజనీర్‌తో ఒకే పరిష్కారాలకు మద్దతు ఇస్తే, ఆ ఇంజనీర్‌లను అప్‌స్ట్రీమ్‌లో బగ్‌లను పరిష్కరించడానికి దారి మళ్లిస్తే, ఒక పరిష్కారాన్ని పోర్ట్ చేయడానికి బదులుగా, వారు సాధారణ ప్రయోజనం కోసం 10 విభిన్న బగ్‌లను పరిష్కరించవచ్చు లేదా ప్రతిపాదిత మార్పుల సమీక్షలో చేరవచ్చు. మరియు బగ్గీ కోడ్‌ను కెర్నల్‌లో చేర్చకుండా నిరోధించండి. పరీక్ష మరియు కోడ్ విశ్లేషణ కోసం కొత్త సాధనాలను రూపొందించడానికి వనరులను కూడా కేటాయించవచ్చు, ఇది ప్రారంభ దశలో మళ్లీ మళ్లీ పాప్ అప్ అయ్యే సాధారణ తరగతుల లోపాలను స్వయంచాలకంగా గుర్తించడానికి అనుమతిస్తుంది.

కీస్ కుక్ కూడా కోర్ డెవలప్‌మెంట్ ప్రాసెస్‌లో నేరుగా ఆటోమేటెడ్ మరియు ఫ్యూజింగ్ టెస్టింగ్‌ని మరింత చురుగ్గా ఉపయోగించాలని, నిరంతర ఏకీకరణ వ్యవస్థలను ఉపయోగించడం మరియు ఇమెయిల్ ద్వారా పురాతన అభివృద్ధి నిర్వహణను వదిలివేయాలని సూచించారు. ప్రస్తుతం, ప్రధాన పరీక్ష ప్రక్రియలు అభివృద్ధి నుండి వేరు చేయబడి విడుదలలు ఏర్పడిన తర్వాత సంభవించే వాస్తవం ద్వారా సమర్థవంతమైన పరీక్షకు ఆటంకం ఏర్పడింది. బగ్‌లను తగ్గించడానికి రస్ట్ వంటి మరింత సురక్షిత భాషలను ఉపయోగించాలని కీలు సిఫార్సు చేశాయి.

మూలం: opennet.ru

ఒక వ్యాఖ్యను జోడించండి