કીઝ કૂક હું એક બ્લોગ પોસ્ટ કરું છું જેમાં બગ ફિક્સિંગ પ્રક્રિયા અંગે ચિંતા વ્યક્ત કરી છે લિનક્સ કર્નલની સ્થિર શાખાઓમાં ચાલુ છે અને તે છે ઉલ્લેખ કરો કે અઠવાડિયામાં અઠવાડિયામાં લગભગ સો સુધારાઓ શામેલ છે સ્થિર શાખાઓ પર, જે ખૂબ વધારે છે અને Linux કર્નલ આધારિત ઉત્પાદનોને જાળવવા માટે ઘણા પ્રયત્નોની જરૂર છે.
કીઝ અનુસાર, કર્નલ એરર હેન્ડલિંગ પ્રક્રિયાને બાયપાસ કરવામાં આવી છે અને કર્નલમાં ઓછામાં ઓછા 100 વધારાના વિકાસકર્તાઓનો અભાવ છે આ વિસ્તારમાં સંકલિત રીતે કામ કરવું. એ ઉલ્લેખ કરવા ઉપરાંત કે મુખ્ય કર્નલ ડેવલપર્સ નિયમિતપણે ભૂલો સુધારે છે, પરંતુ આ ફિક્સ થર્ડ-પાર્ટી કર્નલ વેરિએન્ટ્સ સુધી લઈ જશે તેની કોઈ ગેરંટી નથી.
આમ કરવાથી, તેમણે ઉલ્લેખ કર્યો છે કે વિવિધ લિનક્સ કર્નલ આધારિત ઉત્પાદનોના વપરાશકર્તાઓ પાસે તેમના ઉપકરણો પર કઈ ભૂલો નિશ્ચિત છે અને કઈ કર્નલનો ઉપયોગ થાય છે તે નિયંત્રિત કરવાની કોઈ રીત નથી. છેવટે, વિક્રેતાઓ તેમના ઉત્પાદનોની સલામતી માટે જવાબદાર છે, પરંતુ સ્થિર કર્નલ શાખાઓ પર ખૂબ જ patંચા દરનો સામનો કરવો પડ્યો હતો, તેમને તમામ પેચોને સ્થાનાંતરિત કરવાની પસંદગી, સૌથી મહત્વપૂર્ણને પસંદગીયુક્ત રીતે સ્થાનાંતરિત કરવાની, અથવા તમામ પેચો પેચોની અવગણનાનો સામનો કરવો પડ્યો હતો. .
અપસ્ટ્રીમ કર્નલ ડેવલપર્સ ભૂલોને ઠીક કરી શકે છે, પરંતુ ડાઉનસ્ટ્રીમ વિક્રેતા તેમના ઉત્પાદનોમાં સમાવવા માટે શું પસંદ કરે છે તેના પર તેમનું કોઈ નિયંત્રણ નથી. અંતિમ વપરાશકર્તાઓ તેમની પ્રોડક્ટ્સ પસંદ કરી શકે છે, પરંતુ સામાન્ય રીતે તેઓ પર કોઈ નિયંત્રણ નથી કે કઈ ભૂલો સુધારેલ છે અથવા કઈ કર્નલનો ઉપયોગ કરવામાં આવે છે (પોતે અને એક સમસ્યા). આખરે, વિક્રેતાઓ તેમના ઉત્પાદન કોરોને સુરક્ષિત રાખવા માટે જવાબદાર છે.
કીઝ કૂક સૂચવે છે કે શ્રેષ્ઠ ઉકેલ માત્ર સૌથી મહત્વપૂર્ણ સુધારાઓ અને નબળાઈઓને સ્થાનાંતરિત કરવાનો રહેશે, પરંતુ મુખ્ય સમસ્યા આ ભૂલોને સામાન્ય પ્રવાહથી અલગ કરવાની છે, કારણ કે મોટાભાગની ઉભરતી સમસ્યાઓ C ભાષાના ઉપયોગનું પરિણામ છે, જેને મેમરી અને પોઇન્ટર સાથે કામ કરતી વખતે ઘણી કાળજીની જરૂર પડે છે.
બાબતોને વધુ ખરાબ કરવા માટે, ઘણા સંભવિત નબળાઈના સુધારાઓને CVE ઓળખકર્તા સાથે ટેગ કરવામાં આવતા નથી અથવા પેચ છૂટા થયાના અમુક સમય પછી CVE ઓળખકર્તા પ્રાપ્ત થતા નથી.
આવા વાતાવરણમાં, ઉત્પાદકો માટે નાના સુરક્ષાને મુખ્ય સુરક્ષા મુદ્દાઓથી અલગ કરવું ખૂબ જ મુશ્કેલ છે. આંકડા અનુસાર, CVE સોંપણી પહેલા 40% થી વધુ નબળાઈઓ દૂર કરવામાં આવે છે, અને સરેરાશ ફિક્સ રિલીઝ અને CVE સોંપણી વચ્ચેનો વિલંબ ત્રણ મહિનાનો હોય છે (એટલે કે, શરૂઆતમાં, એક સામાન્ય ભૂલ તરીકે ઉકેલ માને છે,
પરિણામે, નબળાઈઓ માટે સુધારાઓ સાથે અલગ શાખા નથી અને આ અથવા તે સમસ્યાની સુરક્ષા સાથેના જોડાણ વિશેની માહિતી પ્રાપ્ત ન કરવી, લિનક્સ કર્નલ આધારિત ઉત્પાદનોના ઉત્પાદકોએ સતત તમામ સુધારાઓ સ્થાનાંતરિત કરવા પડે છે નવી સ્થિર શાખાઓ. પરંતુ આ કામ શ્રમ-સઘન છે અને રિગ્રેસિવ ફેરફારોના ડરને કારણે કંપનીઓના પ્રતિકારનો સામનો કરે છે જે ઉત્પાદનની સામાન્ય કામગીરીને ખોરવી શકે છે.
કીઝ કૂક માને છે કે લાંબા ગાળે વાજબી કિંમતે કર્નલને સુરક્ષિત રાખવાનો એકમાત્ર ઉપાય પેચ એન્જિનિયરોને સ્થાનાંતરિત કરવાનો છે પાગલ કર્નલ બનાવવા માટેl સંકલિત રીતે સાથે મળીને કામ કરવું અપસ્ટ્રીમ કર્નલમાં પેચો અને નબળાઈઓ જાળવવા. જેમ કે તે standsભું છે, ઘણા વિક્રેતાઓ તેમના ઉત્પાદનોમાં નવીનતમ કર્નલ સંસ્કરણોનો ઉપયોગ કરતા નથી અને તેમના પોતાના પર બેકપોર્ટ ફિક્સ કરે છે, જેનો અર્થ છે કે વિવિધ કંપનીઓના એન્જિનિયરો એક જ સમસ્યાને હલ કરીને એકબીજાના કામની નકલ કરવા માટે બહાર આવે છે.
ઉદાહરણ તરીકે, જો 10 કંપનીઓ, જે દરેક એન્જિનિયર સમાન સુધારાઓને ટેકો આપે છે, આ ઇજનેરોને એક સુધારાને સ્થાનાંતરિત કરવાને બદલે અપસ્ટ્રીમ ભૂલો સુધારવા માટે રીડાયરેક્ટ કરે છે, તો તેઓ એકંદર લાભ માટે 10 અલગ અલગ ભૂલો સુધારી શકે છે અથવા ભૂલોની સમીક્ષા કરવા માટે ભેગા થઈ શકે છે. સૂચિત ફેરફારો . અને કર્નલમાં બગી કોડ શામેલ કરવાનું ટાળો. સંસાધનોનો ઉપયોગ નવા કોડ વિશ્લેષણ અને પરીક્ષણ સાધનો બનાવવા માટે પણ થઈ શકે છે જે પ્રારંભિક તબક્કે આપમેળે લાક્ષણિક ભૂલ વર્ગોને શોધી કાે છે જે વારંવાર અને ફરીથી ઉગે છે.
કીઝ કૂક ઓટોમેટેડ ટેસ્ટિંગ અને ફઝિંગનો વધુ સક્રિયપણે ઉપયોગ કરવાની દરખાસ્ત પણ કરે છે સીધા કર્નલ વિકાસ પ્રક્રિયામાં, સતત એકીકરણ પ્રણાલીઓનો ઉપયોગ કરો અને ઈ-મેલ દ્વારા વિકાસના પ્રાચીન વ્યવસ્થાપનનો ત્યાગ કરો.
સ્રોત: https://security.googleblog.com