Kīss Kuks, bijušais kernel.org galvenais sistēmas administrators un Ubuntu drošības komandas vadītājs, kurš tagad strādā Google, lai nodrošinātu Android un ChromeOS drošību, pauda bažas par pašreizējo kļūdu labošanas procesu stabilajos kodola atzaros. Katru nedēļu stabilajos zaros tiek iekļauti aptuveni simts labojumu, un pēc izmaiņu pieņemšanas loga aizvēršanas nākamajā laidienā tas tuvojas tūkstotim (uzturētāji tur labojumus līdz loga aizvēršanai, un pēc “ -rc1” viņi uzreiz publicē uzkrātos), kas ir pārāk daudz un prasa daudz darbaspēka uzturēšanas produktiem, kuru pamatā ir Linux kodols.
Pēc Kīsa domām, procesam ar kļūdām kodolā netiek pievērsta pienācīga uzmanība un kodolam trūkst vismaz 100 papildu izstrādātāju saskaņotam darbam šajā jomā. Galvenie kodola izstrādātāji regulāri labo kļūdas, taču nav garantijas, ka šie labojumi tiks pārnesti uz kodola variantiem, ko izmanto trešās puses. Dažādu uz Linux kodolu balstītu produktu lietotājiem arī nav iespējas kontrolēt, kuras kļūdas tiek novērstas un kurš kodols tiek izmantots viņu ierīcēs. Galu galā ražotāji ir atbildīgi par savu produktu drošību, taču ar ļoti augsto labojumu publicēšanas intensitāti stabilos kodola zaros viņi bija izvēles priekšā - portēt visus labojumus, selektīvi portēt svarīgākos vai ignorēt visus labojumus. .
Optimālais risinājums būtu migrēt tikai svarīgākos labojumus un ievainojamības, taču galvenā problēma ir šādu kļūdu izolēšana no vispārējās plūsmas. Lielākais uznirstošo problēmu skaits ir C valodas lietošanas sekas, kas prasa lielu piesardzību, strādājot ar atmiņu un rādītājiem. Situāciju pasliktina tas, ka daudzi potenciālie ievainojamības ielāpi nav nodrošināti ar CVE identifikatoru vai tiem tiek piešķirts CVE identifikators kādu laiku pēc ielāpa publicēšanas. Šādā vidē ražotājiem ir ļoti grūti nodalīt nelielus labojumus no svarīgiem drošības jautājumiem. Saskaņā ar statistiku vairāk nekā 40% ievainojamību tiek novērstas pirms CVE piešķiršanas, un vidēji aizkave starp labojuma izlaišanu un CVE piešķiršanu ir trīs mēneši (t.i., sākumā labojums tiek uztverts kā regulāra kļūda, taču tikai pēc vairākiem mēnešiem kļūst skaidrs, ka ievainojamība ir novērsta).
Rezultātā bez atsevišķas atzaras ar ievainojamību labojumiem un nesaņemot informāciju par konkrētas problēmas drošības savienojumu, uz Linux kodola bāzes ražoto produktu ražotājiem atliek nepārtraukti pārsūtīt visus labojumus no jaunākajiem stabilajiem zariem. Bet šis darbs prasa daudz darbaspēka un saskaras ar pretestību uzņēmumos, jo baidās no regresīvu izmaiņu rašanās, kas varētu traucēt produkta normālu darbību.
Atgādināsim, ka pēc Linusa Torvalda domām, visas kļūdas ir svarīgas un ievainojamības nevajadzētu nodalīt no cita veida kļūdām un iedalīt atsevišķā augstākas prioritātes kategorijā. Šāds viedoklis tiek skaidrots ar to, ka parastam izstrādātājam, kurš nav specializējies drošības jautājumos, saikne starp labojumu un iespējamo ievainojamību nav acīmredzama (daudziem labojumiem tikai atsevišķs audits ļauj saprast, ka tie attiecas uz drošību ). Pēc Linusa domām, drošības speciālistiem no komandām, kuras ir atbildīgas par kodola pakotņu uzturēšanu Linux izplatījumos, ir jāiesaista iespējamās ievainojamības no vispārējā ielāpu straumes.
Kīss Kuks uzskata, ka vienīgais risinājums kodola drošības uzturēšanai par saprātīgām ilgtermiņa izmaksām ir uzņēmumiem pārvietot inženierus, kas ir iesaistīti labojumu pārnešanā uz vietējiem kodola būvējumiem, kopīgiem, koordinētiem centieniem uzturēt labojumus un ievainojamības galvenajā kodolā (augšupstraumē). ). Pašreizējā formā daudzi ražotāji savos produktos izmanto ne jaunākās kodola versijas un pārsūta labojumus iekšēji, t.i. Izrādās, ka inženieri dažādos uzņēmumos dublē viens otra darbu, risinot vienu un to pašu problēmu.
Piemēram, ja 10 uzņēmumi, katrs ar vienu inženieri, kurš nodrošina tos pašus labojumus, atkārtoti uzticētu šiem inženieriem labot kļūdas iepriekšējā straumē, tad tā vietā, lai pārnestu vienu labojumu, tie varētu labot 10 dažādas kļūdas kopējā labā vai pievienoties ierosināto izmaiņu pārskatīšanai. un novērstu kļūdaina koda iekļaušanu kodolā. Resursus varētu veltīt arī jaunu rīku izveidei koda testēšanai un analīzei, kas ļautu agrīni atklāt bieži sastopamas kļūdu klases, kas parādās atkal un atkal.
Kīss Kuks arī iesaka aktīvāk izmantot automatizētu un neskaidru testēšanu tieši kodola izstrādes procesā, izmantojot nepārtrauktas integrācijas sistēmas un atsakoties no arhaiskas izstrādes pārvaldības pa e-pastu. Pašlaik efektīvu testēšanu apgrūtina fakts, ka galvenie testēšanas procesi ir atdalīti no izstrādes un notiek pēc izlaidumu izveidošanas. Keys arī ieteica izmantot valodas, kas nodrošina augstāku drošības līmeni, piemēram, Rust, izstrādājot, lai samazinātu kļūdu skaitu.
Avots: opennet.ru