{"id":100924,"date":"2021-08-05T22:22:35","date_gmt":"2021-08-05T20:22:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux"},"modified":"2026-02-08T16:56:03","modified_gmt":"2026-02-08T14:56:03","slug":"kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/news\/kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux","title":{"rendered":"Google'i Kic Cook kutsus \u00fcles moderniseerima Linuxi kernelis veaprotsessi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Kees Cook, endine kernel.org peamine s\u00fcsteemiadministraator ja Ubuntu Security Teami juht, kes praegu t\u00f6\u00f6tab Google'is Androidi ja ChromeOS'i turvamise nimel, v\u00e4ljendas muret praeguse veaparanduse protsessi \u00fcle stabiilsetes tuumavaldkondades. Igal n\u00e4dalal lisatakse stabiilsetesse harudesse umbes sada parandust, ja p\u00e4rast muutuste vastuv\u00f5tmise akna sulgemist j\u00f5uab need peaaegu tuhande juurde (arendajad hoiavad parandused akna sulgemiseni, ja p\u00e4rast -rc1 kujunemist avaldavad nad samaaegselt akumuleeritud parandused), mis on liiga palju ja vajab rohkem t\u00f6\u00f6j\u00f5udu Linuxi tuumal p\u00f5hinevate toodete hooldamiseks.<\/p>\n
Kees arvates ei p\u00f6\u00f6rata tuuma veateateprotsessile piisavalt t\u00e4helepanu ja tuumal puudub v\u00e4hemalt 100 lisaarendajat koordineeritud t\u00f6\u00f6ks. Peamised tuuma arendajad parandavad pidevalt vigu, kuid puuduvad igasugused garantiid, et need parandused kantakse \u00fcle kolmandate osapoolte tootjate kasutatavatesse tuumaversioonidesse. Erinevate Linuxi tuumal p\u00f5hinevate toodete kasutajatel puudub samuti v\u00f5imalus j\u00e4lgida, milliseid vigu on parandatud ja millist tuuma nende seadmetes kasutatakse. L\u00f5puks vastutavad tootjad oma toodete turvalisuse eest, kuid v\u00e4ga intensiivse paranduste avaldamise t\u00f5ttu stabiilsetes tuuma harudes seisavad nad silmitsi valikuga \u2014 kas kanda k\u00f5ik parandused \u00fcle, valida ainult t\u00e4htsamad v\u00f5i ignoreerida k\u00f5iki parandusi.<\/p>\n
<\/center>Optimaalne lahendus oleks kanda edasi vaid k\u00f5ige olulisemad parandused ja haavatavused, kuid selliste vigade eristamine \u00fcldisest voost on peamine probleem. K\u00f5ige rohkem esinevaid probleeme p\u00f5hjustab C-keele kasutamine, mis n\u00f5uab m\u00e4lu ja n\u00e4idikute k\u00e4sitlemisel suurt t\u00e4helepanu. Probleemi s\u00fcvendab see, et paljud v\u00f5imalike haavatavuste parandused ei ole varustatud CVE-identifikaatoritega v\u00f5i saavad sellise identifikaatori alles p\u00e4rast paranduse avaldamist. Sellistes tingimustes on tootjatel v\u00e4ga keeruline eristada teisej\u00e4rgulisi parandusi olulistest probleemidest, mis m\u00f5jutavad turvalisust. Statistika kohaselt k\u00f5rvaldatakse rohkem kui 40% haavatavustest enne CVE m\u00e4\u00e4ramist, ja keskmine viivitus paranduse avaldamise ja CVE m\u00e4\u00e4ramise vahel on kolm kuud (ehkki alguses tajutakse parandust tavalise veana, selgub alles paar kuud hiljem, et on toimunud haavatavuse k\u00f5rvaldamine).<\/p>\n
L\u00f5ppkokkuv\u00f5ttes, puudumisel eraldi harudest haavatavuste paranduste jaoks ja teabe puudumisel konkreetse probleemiga seotud turvalisusest, peavad Linuxi tuumal p\u00f5hinevate toodete tootjad pidevalt kandma k\u00f5ik parandused v\u00e4rsketesse stabiilsetesse harudesse. Kuid see t\u00f6\u00f6 n\u00f5uab suuremaid ressursse ja ettev\u00f5tetes koheldakse seda vastupanu t\u00f5ttu hirmu regresseerivate muudatuste tekkimise ees, mis v\u00f5ivad kahjustada toote normaalset toimimist.<\/p>\n
Tuletame meelde, et Linus Torvalds arvab, et k\u00f5ik vead on olulised ja haavatavusi ei tohiks eraldada teistest vigadest ning seada neid k\u00f5rgema prioriteediga kategooriasse. Seda seisukohta p\u00f5hjendatakse sellega, et tavaliseks arendajaks, kes ei spetsialiseeru turvalisuse k\u00fcsimustele, ei ole ilmselge seos paranduse ja v\u00f5imaliku haavatavusega (paljude paranduste puhul aitab eraldi auditi l\u00e4biviimine m\u00f5ista, et need on seotud turvalisusega). Linuse arvates peaksid potentsiaalsete haavatavuste eristamisega tegelema turvaspetsialistid, kes kuuluvad nende r\u00fchmade koosseisu, kes vastutavad Linuxi distributsioonide tuuma pakettide hoidmise eest.<\/p>\n
Kees Cook usub, et ainus lahendus tuuma turvalisuse s\u00e4ilitamiseks m\u00f5istlike pikaajaliste kuludega on ettev\u00f5tete inseneride suunamine, kes tegelevad paranduste portleerimisega kohandatud tuumakogude, et t\u00f6\u00f6tada koos koordineeritud viisil p\u00f5hisisu (upstream) hooldamise. Praeguses olukorras kasutavad paljud tootjad oma toodetes mitte k\u00f5ige uuemaid tuumaversioone ja bckportivad parandused ise, mille tulemusena dubleerivad erinevate ettev\u00f5tete insenerid \u00fcksteise t\u00f6\u00f6d, lahendades sama probleemi.<\/p>\n
N\u00e4iteks kui 10 ettev\u00f5tet, kus igas ettev\u00f5ttes tegeleb \u00fcks insener samade paranduste tagasiviimisega, suunaks need insenerid vigu parandama upstream, siis oleks nad v\u00f5inud \u00fche paranduse portimise asemel parandada 10 erinevat viga \u00fchise h\u00fcvena v\u00f5i liituda pakutud muudatuste \u00fclevaatamisega, et v\u00e4ltida vigase koodi kaasamist tuuma. Ressursse oleks samuti saanud suunata uute testimise ja koodi anal\u00fc\u00fcsi t\u00f6\u00f6riistade loomisse, mis v\u00f5imaldaksid automaatselt avastada t\u00fc\u00fcpilisi vigu varases etapis, mis j\u00e4lle ja j\u00e4lle pinnale tulevad.<\/p>\n
Kees Cook kutsub \u00fcles kasutama automatiseeritud ja fuzzing-teste aktiivsemalt tuuma arendamise protsessi, rakendama pideva integreerimise s\u00fcsteeme ning loobuma vananenud arenduse juhtimisest e-posti teel. Praegu takistab t\u00f5husat testimist see, et peamised testimisprotsessid on eraldatud arendamisest ja toimuvad alles p\u00e4rast versioonide loomist. Kees soovitas samuti veakoguse v\u00e4hendamiseks arendamisel kasutada keeli, mis tagavad rohkem k\u00f5rget turvataset<\/a>, nagu Rust.<\/p>\n
![\"Google'i](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>Optimaalne lahendus oleks kanda edasi vaid k\u00f5ige olulisemad parandused ja haavatavused, kuid selliste vigade eristamine \u00fcldisest voost on peamine probleem. K\u00f5ige rohkem esinevaid probleeme p\u00f5hjustab C-keele kasutamine, mis n\u00f5uab m\u00e4lu ja n\u00e4idikute k\u00e4sitlemisel suurt t\u00e4helepanu. Probleemi s\u00fcvendab see, et paljud v\u00f5imalike haavatavuste parandused ei ole varustatud CVE-identifikaatoritega v\u00f5i saavad sellise identifikaatori alles p\u00e4rast paranduse avaldamist. Sellistes tingimustes on tootjatel v\u00e4ga keeruline eristada teisej\u00e4rgulisi parandusi olulistest probleemidest, mis m\u00f5jutavad turvalisust. Statistika kohaselt k\u00f5rvaldatakse rohkem kui 40% haavatavustest enne CVE m\u00e4\u00e4ramist, ja keskmine viivitus paranduse avaldamise ja CVE m\u00e4\u00e4ramise vahel on kolm kuud (ehkki alguses tajutakse parandust tavalise veana, selgub alles paar kuud hiljem, et on toimunud haavatavuse k\u00f5rvaldamine).<\/p>\n