Кейс Кук (Kees Cook), бывший главный системный администратор kernel.org и лидер Ubuntu Security Team, ныне работающий в компании Google над обеспечением защиты Android и ChromeOS, выразил опасение текущим процессом исправления ошибок в стабильных ветках ядра. Еженедельно в стабильные ветки включается около ста исправлений, а после закрытия окна приёма изменений в следующий релиз приближается к тысяче (сопровождающие удерживают исправления до закрытия окна, а после формирования "-rc1" публикуют накопившееся разом), что слишком много и требует больших трудозатрат для сопровождения продуктов на базе ядра Linux.

По мнению Кейса процессу работы с ошибками в ядре не уделяется должное внимание и ядру не хватает как минимум 100 дополнительных разработчиков для скоординированной работы в этой области. Основные разработчики ядра регулярно исправляют ошибки, но нет никаких гарантий, что эти исправления будут перенесены в варианты ядра, используемые сторонними производителями. У пользователей различных продуктов на базе ядра Linux также нет возможности проконтролировать то, какие ошибки исправлены и какое ядро используется в их устройствах. В конечном счёте за безопасность своих продуктов отвечают производители, но в условиях очень большой интенсивности публикации исправлений в стабильных ветках ядра они оказались поставлены перед выбором - переносить все исправления, выборочно портировать самое важное или игнорировать все исправления.

Оптимальным решением был бы перенос только самых важных исправлений ошибок и уязвимостей, но в выделении подобных патчей из общего потока и состоит основная проблема. Наибольшее число всплывающих проблем является следствием использования языка Си, требующего большой аккуратности при работе с памятью и указателями. Усугубляет ситуацию то, что многие потенциальные исправления уязвимостей не снабжаются идентификаторами CVE или получают подобный идентификатор через какое-то время после публикации исправления. В подобных условиях производителям очень трудно разделить второстепенные исправления от важных проблем, влияющих на безопасность. По статистике более 40% уязвимостей устраняются до присвоения CVE и в среднем задержка между выпуском исправления и присвоением CVE составляет три месяца (т.е. вначале исправление воспринимается как обычная ошибка, но лишь спустя несколько месяцев становится ясно, что имело место устранение узявимости).

В итоге, не имея отдельной ветки с исправлениями уязвимостей и не получая сведений о связи с безопасностью той или иной проблемы, производителям продуктов на базе ядра Linux остаётся непрерывно переносить все исправления из свежих стабильных веток. Но данная работа требует больших трудозатрат и сталкивается в компаниях с сопротивлением из-за опасения в появлении регрессивных изменений, способных нарушить нормальную работу продукта.

Напомним, что по мнению Линуса Торвальдса, все ошибки важны и уязвимости не следует отделять от других видов ошибок и выделять в отдельную более приоритетную категорию. Объясняется такое мнение тем, что для обычного разработчика, не специализирующегося на вопросах безопасности, не очевидна связь исправления с потенциальной уязвимостью (для многих исправлений лишь проведение отдельного аудита позволяет понять, что они касаются безопасности). По мнению Линуса, вопросами выделения из общего потока исправлений потенциальных уязвимостей должны заниматься специалисты по безопасности из команд, отвечающих за поддержку пакетов с ядром в дистрибутивах Linux.

Кейс Кук считает, что единственным решением для поддержания безопасности ядра при разумных долгосрочных затратах является перевод компаниями инженеров, занимающихся портированием исправлений в локальные сборки ядра, к совместной скоординированной работе над сопровождением исправлений и уязвимостей в основном ядре (upstream). В текущем виде, многие производители используют в своих продуктах не самые новые версии ядра и бэкпортируют исправления собственными силами, т.е. получается, что инженеры в разных компаниях дублируют работу друг друга, решая одну и ту же проблему.

Например, если 10 компаний, в каждой из которых один инженер занимается бэкпорированием одних и тех же исправлений, переориентируют данных инженеров на исправление ошибок в upstream, то они вместо портирования одного исправления могли бы исправить 10 разных ошибок для общей пользы или подключиться к рецензированию предлагаемых изменений и не допустить включения кода с ошибками в ядро. Ресурсы также можно было бы направить на создание новых инструментов для тестирования и анализа кода, которые позволили бы на ранней стадии автоматически выявлять типовые классы ошибок, которые всплывают вновь и вновь.

Кейс Кук также предлагает более активно использовать автоматизированное и fuzzing-тестирование непосредственно в процессе разработки ядра, применять системы непрерывной интеграции и отказаться от архаичного управления разработкой через email. В настоящее время эффективному тестированию мешает то, что основные процессы тестирования отделены от разработки и происходят уже после формирования релизов. Кейс также рекомендовал для снижения числа ошибок применять при разработке языки, обеспечивающие более высокий уровень безопасности, такие как Rust.