Kees kuhati Napravim blog post u kojem je izazvao zabrinutost zbog procesa ispravljanja grešaka u tijeku u stabilnim granama jezgre Linuxa i je li to spomenuti da je tjedan po tjedan uključeno stotinjak ispravki na stabilnim granama, što je previše i zahtijeva puno truda za održavanje proizvoda temeljenih na jezgri Linuxa.
Prema Keesu, proces rukovanja pogreškama jezgre je zaobiđen i kernelu nedostaje najmanje 100 dodatnih programera da koordinirano rade na ovom području. Uz napomenu da veliki programeri jezgre redovito ispravljaju greške, ali nema jamstva da će se ti popravci prenijeti na varijante jezgre trećih strana.
Pritom spominje da korisnici različitih proizvoda temeljenih na jezgri Linuxa također nemaju načina kontrolirati koje su greške ispravljene i koje se jezgro koristi na njihovim uređajima. U konačnici, dobavljači su odgovorni za sigurnost svojih proizvoda, no suočeni s vrlo velikom stopom zakrpa na stabilnim granama jezgre, suočeni su s izborom migracije svih zakrpa, selektivne migracije najvažnijih ili zanemarivanja svih zakrpa. .
Razvojni programeri jezgre mogu popraviti greške, ali nemaju kontrolu nad onim što dobavljač daljeg toka odlučuje ugraditi u svoje proizvode. Krajnji korisnici mogu birati svoje proizvode, ali općenito nemaju kontrolu nad ispravljenim greškama niti jezgrom koja se koristi (problem sam po sebi). U konačnici, prodavači su odgovorni za očuvanje jezgre svojih proizvoda.
Kees kuhati sugerira da bi optimalno rješenje bilo prijenos samo najvažnijih popravaka i ranjivosti, ali glavni problem je odvojiti ove pogreške od općeg tijeka, budući da je većina nastajućih problema posljedica korištenja jezika C, koji zahtijeva puno pažnje pri radu s memorijom i pokazivačima.
Da stvar bude gora, mnogi potencijalni popravci ranjivosti nisu označeni CVE identifikatorima ili ne primaju CVE identifikator neko vrijeme nakon objavljivanja zakrpe.
U takvom okruženju proizvođačima je vrlo teško odvojiti manje popravke od velikih sigurnosnih problema. Prema statistikama, više od 40% ranjivosti uklanja se prije dodjele CVE -a, a u prosjeku je kašnjenje između izdanja popravka i dodjele CVE -a tri mjeseca (to jest, na početku se rješenje smatra uobičajenom greškom,
Kao rezultat toga, nema zasebnu granu s popravcima za ranjivosti i ne prima informacije o vezi sa sigurnošću ovog ili onog problema, proizvođači proizvoda temeljenih na jezgri Linuxa moraju stalno prenositi sve popravke novih stabilnih grana. No, ovaj posao je radno intenzivan i nailazi na otpor tvrtki zbog straha od regresivnih promjena koje bi mogle poremetiti normalan rad proizvoda.
Ključevi Kuhar vjeruje da je jedino rješenje za održavanje jezgre sigurnom po razumnoj cijeni na duži rok premještanje inženjera zakrpa do ludih jezgri gradil raditi zajedno na koordiniran način za održavanje zakrpa i ranjivosti u uzvodnoj jezgri. Kako sada stoji, mnogi dobavljači ne koriste najnovije verzije jezgre u svojim proizvodima i popravke zaostalih podataka, što znači da se inženjeri iz različitih tvrtki međusobno dupliciraju, rješavajući isti problem.
Na primjer, ako 10 tvrtki, od kojih svaka ima inženjera koji podržava iste popravke, preusmjeri te inženjere da popravljaju greške uzvodno, umjesto da migriraju jedno popravljanje, mogle bi popraviti 10 različitih grešaka radi sveukupne koristi ili doći zajedno kako bi pregledale greške. Predložene izmjene . I izbjegavajte uključivanje grešaka u jezgru. Resursi se također mogu koristiti za stvaranje novih alata za analizu koda i testiranje koji bi automatski u ranoj fazi automatski otkrili tipične klase pogrešaka koje se pojavljuju uvijek iznova.
Ključevi Kuhar također predlaže aktivniju uporabu automatiziranog testiranja i fuzzinga izravno u procesu razvoja jezgre, koristiti sustave kontinuirane integracije i napustiti arhaično upravljanje razvojem putem e-pošte.
izvor: https://security.googleblog.com