Кеес Цоок, бивши главни систем администратор кернел.орг и вођа Убунту безбедносног тима који сада ради у Гуглу на заштити Андроида и ЦхромеОС-а, изразио је забринутост због тренутног процеса поправљања грешака у стабилним гранама кернела. Сваке недеље се у стабилне гране укључи око сто поправки, а након што се затвори прозор за прихватање измена у следећем издању, приближава се хиљаду (одржавачи држе поправке док се прозор не затвори, а након формирања „ -рц1” објављују акумулиране одједном), што је превише и захтева много рада за производе за одржавање засноване на језгру Линука.
Према Кису, процесу рада са грешкама у кернелу се не поклања дужна пажња и кернелу недостаје најмање 100 додатних програмера за координисан рад у овој области. Главни програмери кернела редовно исправљају грешке, али не постоји гаранција да ће ове исправке бити пренете на варијанте кернела које користе треће стране. Корисници различитих производа заснованих на Линук кернелу такође немају начин да контролишу које грешке су исправљене и које језгро се користи у њиховим уређајима. На крају крајева, произвођачи су одговорни за безбедност својих производа, али са веома високим интензитетом објављивања поправки у стабилним гранама кернела, били су суочени са избором - пренети све поправке, селективно портирати најважније или игнорисати све поправке .
Оптимално решење би било да се мигрирају само најважније исправке и рањивости, али изоловање таквих грешака из општег тока представља главни проблем. Највећи број проблема који се појављују последица је коришћења језика Ц, који захтева велику пажњу при раду са меморијом и показивачима. Да ствар буде гора, многе потенцијалне закрпе рањивости немају ЦВЕ идентификатор или им је додељен ЦВЕ идентификатор неко време након што је закрпа објављена. У таквом окружењу произвођачима је веома тешко да одвоје мање поправке од важних безбедносних проблема. Према статистикама, више од 40% рањивости је поправљено пре него што је ЦВЕ додељен, а у просеку кашњење између објављивања поправке и доделе ЦВЕ-а је три месеца (тј. у почетку се исправка доживљава као уобичајена грешка, али тек након неколико месеци постаје јасно да је рањивост исправљена).
Као резултат тога, без посебне гране са исправкама за рањивости и без добијања информација о безбедносној вези одређеног проблема, произвођачима производа заснованих на језгру Линука остаје да континуирано преносе све поправке из најновијих стабилних грана. Али овај посао захтева много труда и суочава се са отпором у компанијама због страха од појаве регресивних промена које би могле да поремете нормалан рад производа.
Подсетимо се да су према Линусу Торвалдсу све грешке важне и рањивости не треба одвајати од других врста грешака и издвајати их у посебну категорију вишег приоритета. Ово мишљење се објашњава чињеницом да за обичног програмера који није специјализован за безбедносна питања, веза између поправке и потенцијалне рањивости није очигледна (за многе поправке, само посебна ревизија омогућава да се схвати да се тичу безбедности ). Према Линусу, стручњаци за безбедност из тимова одговорних за одржавање пакета кернела у Линук дистрибуцијама треба да буду укључени у идентификацију потенцијалних рањивости из општег тока закрпа.
Кеес Цоок верује да је једино решење за одржавање безбедности кернела уз разумну дугорочну цену да компаније преместе инжењере укључене у пренос поправки на локалне уграђене кернеле у заједнички, координисани напор за одржавање поправки и рањивости у главном кернелу (узводно ). У свом тренутном облику, многи произвођачи користе не најновије верзије кернела у својим производима и бацкпорт исправке у кући, тј. Испоставило се да инжењери у различитим компанијама дуплирају једни друге, решавајући исти проблем.
На пример, ако би 10 компанија, од којих свака има по једног инжењера који преноси исте исправке, прерасподелило те инжењере да исправљају грешке у претходном току, онда би уместо да преносе једну исправку уназад, могле да поправе 10 различитих грешака за заједничку корист или да се придруже у прегледу предложених измене и спречити да се грешка код укључи у кернел. Ресурси би се такође могли посветити стварању нових алата за тестирање и анализу кода који би омогућили рано откривање уобичајених класа грешака које се изнова појављују.
Кеес Цоок такође предлаже активније коришћење аутоматизованог и фузинг тестирања директно у процесу развоја кернела, коришћење система континуиране интеграције и напуштање архаичног управљања развојем путем е-поште. Тренутно, ефикасно тестирање је отежано чињеницом да су главни процеси тестирања одвојени од развоја и настају након формирања издања. Кључеви такође препоручују коришћење језика који обезбеђују виши ниво безбедности, као што је Руст, приликом развоја како би се смањио број грешака.
Извор: опеннет.ру