Гугл посчитал io_uring слишком дырявым и отключил его на Android и ChromeOS

Объясните мне, почему самые крутые сишники, хакеры ядра, не могут не плодить дыры в коде?

Потому что люди ошибаются и программисты не исключение.

Потому что пишут на дырявом Си, а не на Rust или хотя бы C++.

Язык позволяет ~всё и в какой-то момент трудно уследить за такими вещами. Особенно, если пишешь не один.

Возможно, потому что это очень сложный софт, на пределе человеческих способностей.

Всего за связанные с io_uring эксплоиты было выплачено вознаграждений на сумму около миллиона долларов, при том, что за всё время существования инициативы общая сумма вознаграждений, выплаченных за уязвимости в ядре Linux, составила 1.8 млн долларов за 42 предоставленных эксплоита для ещё не исправленных уязвимостей (максимальный размер вознаграждения - 133 тысячи долларов).

У меня есть план:

• Добавляем в ядро фичу с хреновой защитой.
• Пишем эксплоиты
• ??????
• PROFIT

А у С++ что есть для предотвращения дыр?

#define NO_VULNERABILITIES true

вложили миллион нефти и отменили - типичное гуглопрожекторство

Диды как обычно.

это очень сложный софт, на пределе человеческих способностей

Что там предельного? Ядро и ядро. Какое-нибудь корпоративное legacy на java с годами превращается в еще более сложное нагромождение. Буфера при этом не рвутся.

Богатые инструменты проверок времени компиляции и кодогенерации (RAII, шаблоны, constexpr, проверка типов). Многий ошибочный код Си просто не скомпилируется если его переписать на C++.

Так потому что тут буфера и есть предметная область.
Ну это мое понимание. На 100% истину не претендую.

У uring во имя производительности пришлось сделать сложный интерфейс, с которым легко получить гонку. Если бы вместо си использовалось safe подмножество rust, то всё бы просто тормозило и потеряло смысл.

зачем его вообще включали (в ядро), вот в чём вопрос;

переусложнённый нестандартный интерфейс и персистентные буферы в юзерспейсе, это гарантированные проблемы. Помятуя давнее: и внутри ядра, оно как-то не вполне хорошо ложится на всё.

Потому что пограмировать учатся на блок-схемах, которые описывают последовательные алгоритмы, а тут асинхронная многопоточная подсистема, для которой количество возможных состояний велико. Понимать такой код сложно, даже если он выглядит простым. Здесь мог бы помочь некоторый инструментарий статического анализа кода, но, видимо, это не про кернел хакеров, да и существующие инструменты не совершенны

https://habr.com/ru/news/742066/

переусложнённый нестандартный интерфейс и персистентные буферы в юзерспейсе, это гарантированные проблемы. Помятуя давнее: и внутри ядра, оно как-то не вполне хорошо ложится на всё.

Потому что диски становятся такими же быстрыми как сеть и деваться от этого факта становится все сложнее и сложнее.

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

Позволяет, но на С трудней уследить за всем, чем на плюсах, и тем более Rust. Там Си много не явного, таже перегрузка функций. То есть, Си, более подвержен человеческому фактору, чем более новые языки.

общий уровень падает

А он везде падает, куда добирается крупняк. Там проще держать винтиков с зоной ответственности 1*1см, чем зависеть от гениев и энтузиастов.

А вот и ещё одна слишком сложная технология

https://www.opennet.ru/opennews/art.shtml?num=59385

Структура «maple tree» представляет собой вариант B-tree, поддерживающий индексацию по диапазонам значений и спроектированный для эффективного использования кэша современных процессоров. По сравнению с «red-black tree» применение «maple tree» позволяет добиться более высокой производительности. Уязвимость вызвана ошибкой в обработчике расширения стека - в структуре «maple tree», используемой при управлении областями виртуальной памяти в ядре, замена узла в дереве могла произойти без выставления блокировки на запись, что создавало условия для обращения к области памяти после её освобождения (use-after-free).

Submitted by Google engineer Matteo Rizzo, the upstream Linux 6.6 kernel is set to add a new sysctl interface for disabling IO_uring system-wide.

https://www.phoronix.com/news/Linux-6.6-sysctl-IO_uring

Почитал комментарии. Какая же духота. Как вообще можно так пресно общаться. Такое ощущения, что у них за спиной стоит трансгендер с плёткой и контролирует написанное.

Со страпоном. Хотя, оно же трансгендер… хотя, непонятно, из чего во что. Пусть будет со страпоном, чтоб наверняка.

Объясните мне, почему самые крутые сишники, хакеры ядра, не могут не плодить дыры в коде?

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

Потому что дело не в сишике или хакерстве

Нет. Дело именно в сишке и хацкерстве. Просто нужно начать превентивно сдавать в дурку людей, пишущих в таком стиле:

do {
    if (*--p == '.') *p = '_';
} while (p != name);

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

Особняком стоит вера сишников, что входные данные их алгоритмов находятся именно в том виде, в котором они думают. Никаких проверок, что в конце строки будет нолик и их чудесный цикл на трёхэтажных инкрементах с разыменованием сможет остановится, они не делают. А потом происходят ойойойой выход за границы буфера с повреждением чужой памяти и торжественное присвоение номера CVE. Но виноват в этом кто угодно кроме сишных хацкеров. Ага.