Кийс Кук Правя публикация в блог, в която изрази опасения относно процеса на отстраняване на грешки продължава в стабилните клонове на ядрото на Linux и това ли е споменете, че седмица след седмица са включени около сто корекции на стабилни клонове, което е твърде много и изисква много усилия за поддържане на продукти, базирани на ядрото на Linux.
Според Кийс, процесът на обработка на грешки в ядрото се заобикаля и на ядрото липсват поне 100 допълнителни разработчици да работят координирано в тази област. В допълнение към споменаването, че големите разработчици на ядро редовно поправят грешки, но няма гаранция, че тези корекции ще се пренесат в варианти на ядрото на трети страни.
При това той споменава, че потребителите на различни продукти, базирани на ядрото на Linux, също нямат начин да контролират кои грешки са отстранени и кое ядро се използва на техните устройства. В крайна сметка доставчиците са отговорни за сигурността на своите продукти, но изправени пред много висок процент на корекции на стабилни клонове на ядрото, те бяха изправени пред избора да мигрират всички кръпки, избирателно да мигрират най -важните или да игнорират всички кръпки. .
Разработчиците на ядрото нагоре по веригата могат да поправят грешки, но нямат контрол върху това, което доставчикът надолу по веригата избере да включи в своите продукти. Крайните потребители могат да избират своите продукти, но обикновено нямат контрол върху това кои грешки са отстранени или кое ядро се използва (проблем сам по себе си). В крайна сметка доставчиците са отговорни за опазването на ядрата на своите продукти.
Кийс Кук предполага, че оптималното решение би било да се прехвърлят само най -важните корекции и уязвимости, но основният проблем е да се отделят тези грешки от общия поток, тъй като повечето от възникващите проблеми са следствие от използването на езика C, което изисква много внимание при работа с памет и указатели.
За да влошат нещата, много потенциални корекции на уязвимости не са маркирани с CVE идентификатори или не получават CVE идентификатор известно време след освобождаването на корекцията.
В такава среда за производителите е много трудно да отделят малки поправки от основните проблеми със сигурността. Според статистиката повече от 40% от уязвимостите се отстраняват преди присвояване на CVE, а средно забавянето между освобождаване на поправка и присвояване на CVE е три месеца (тоест в началото решението се възприема като често срещана грешка,
В резултат на това няма отделен клон с поправки за уязвимостите и не получавате информация за връзката със сигурността на този или онзи проблем, производителите на продукти, базирани на ядрото на Linux, трябва непрекъснато да прехвърлят всички поправки от новите стабилни клонове. Но тази работа е трудоемка и се сблъсква с съпротива от компаниите поради опасения от регресивни промени, които биха могли да нарушат нормалната работа на продукта.
Ключове Кук вярва, че единственото решение за запазване на ядрото на разумна цена в дългосрочен план е преместването на инженери за кръпки за луди изгражда ядроl да работим заедно по координиран начин за поддържане на корекции и уязвимости в ядрото нагоре по веригата. Както изглежда, много доставчици не използват най -новите версии на ядрото в своите продукти и корекции на backport сами, тоест се оказва, че инженери от различни компании си дублират работата, решавайки един и същ проблем.
Например, ако 10 компании, всяка с инженер, поддържащ същите поправки, пренасочат тези инженери, за да поправят грешки нагоре по веригата, вместо да мигрират една корекция, те биха могли да поправят 10 различни грешки за общата полза или да се съберат заедно, за да прегледат грешките. Предложени промени . И избягвайте включването на бъги код в ядрото. Ресурсите могат да бъдат използвани и за създаване на нови инструменти за анализ и тестване на кода, които автоматично да откриват на ранен етап типичните класове на грешки, които се появяват отново и отново.
Ключове Кук предлага също така по -активно използване на автоматизирано тестване и размиване директно в процеса на разработка на ядрото, използвайте системи за непрекъсната интеграция и изоставете архаичното управление на развитието чрез електронна поща.
Fuente: https://security.googleblog.com