Новые серьезные уязвимости в ядре Linux и systemd

Что такое голый массив?

char arr[64];

Если есть голый, то должен быть одетый массив)))

String<64> arr();

Ты свои же новости не читаешь, да? У шапки affeted только семерка

Но я всё равно придерживаюсь своего мнения: зачем переизобретать C++, если уже есть готовое и стандартное?

Готовое и стандартное не всегда подходит. Библиотеку на C я могу собрать чем угодно и подключить куда угодно; в C++ же нет стандартного ABI, поэтому будь добр собирать свой проект тем же компилятором (и желательно такой же версией), каким собрана библиотека. При наличии исходников проблем нет, но это условие выполняется далеко не всегда, увы.

Ну и некоторых синтаксических конструкций в стандартном C++ нет — это к тому, что C++ не является строгим надмножеством C, как многие считают.

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

с++ во все платформы могёт, что и gcc, а значит, заведомо умеет во все платформы, на которых можно запустить линукс

способы отстрелить себе ногу там за десятилетия хорошо изучены

Кем изучены? Разработчиками линукс? Тогда про что мы тут говорим?

Библиотеку на C я могу собрать чем угодно

С attribute((cleanup(…))) - не чем угодно.

некоторых синтаксических конструкций в стандартном C++ нет

Там настолько мелочь, что вспоминать это можно только чтоб придраться.

позволяет писать с полным пониманием того, что происходит под капотом

s/позволяет/заставляет. Это значит, что на предметную область понимания останется меньше, ибо ресурсы разработчика небезграничны.

// другой анон

с++ во все платформы могёт, что и gcc, а значит, заведомо умеет во все платформы, на которых можно запустить линукс

Разве все языки которые поддерживает gcc могут во все платформы и архитектуры? Там разве не индивидуально всё?

из-за отсутствия толстых абстракций, что позволяет писать с полным пониманием того, что происходит под капотом

А по факту будешь ласапедить очень кривые аналоги std::map или std::vector. Без исключений, шаблонов и прочих очень нужных вещей.

Кем изучены? Разработчиками линукс? Тогда про что мы тут говорим?

Изучены профессиональными разработчиками на C. Это не является 100% страховкой от ошибок, если вы не в курсе. Однако при всей огромности современных стандартов C++, книга «Как не отстрелить себе ногу на C++» будет на порядок толще даже самых современных стандартов.

C++ чрезвычайно переусложнён, и его проблемы стараются решать ещё большим нагромождением абстракций, в результате чего и читать, и писать такой код становится больно.

Я при этом не выступаю с утверждением «Все программы должны писаться на C вместо C++»; анонимный товарищ выше спросил, зачем могут выбирать C при живом C++ — я ответил. Можно привести и множество причин обратного.

ещё большим нагромождением абстракций

Абстракции сильно помогают, т.к. дают очень надежный код. Это надо очень сильно постараться, чтобы сделать ошибку при работе c std.

в C++ же нет стандартного ABI

Это миф. extern "C" как раз означает «стабильное ABI» (то же самое, что всякие JNI, «Platform», FFE и прочее). Это часть языка C++.

поэтому будь добр собирать свой проект тем же компилятором (и желательно такой же версией), каким собрана библиотека.

Сочувсвую, если тебе приходится с таким сталкиваться. Особенно, если это в конторе, где API утверджается на уровне собрания акционеров.

На практике или же весь дистрибьютив собирается одним компилятором (ну может кроме Gentoo). Или же надо использовать пакетный менеджер. Conan для меня эту проблему очень хорошо решил. И потом, почти все новые языки в том или ином виде так делают - Go, Rust.

И еще: в «толстом» интерфейсе гораздо легче работать - можно вернуть вектор, можно бросить исключение. Решив проблему бинарной совместимости менеджером пакетов я вижу необходимость в C ABI только для работы с разными языками. Но это никогда не было легко…

Ну и некоторых синтаксических конструкций в стандартном C++ нет — это к тому, что C++ не является строгим надмножеством C, как многие считают.

Ты про массивы переменной длины на стеке? Да, что-то было такое, но от этого были бы рады и разработчики C (ISO WG) отказаться…

Для чего-то не сильно огромного он подходит очень даже неплохо, в том числе как раз из-за отсутствия толстых абстракций, что позволяет писать с полным пониманием того, что происходит под капотом.

«маленькое» - это как? набросать +- Hello World-утилитку? Так тут меньше всего хочется следить за памятью. Если «отработать и выйти», так вообще GC будет намного проще.

Если маленькое по размеру бинарника… то я вполне успешно на C++ под STM32F1 мигалки делал. Никто же не заставляет всегда абстракции лепить. Только там, где надо.

Кстати, про Embedded - HAL та еще ужасная абстракция на C… Смотрел на некоторые проекты плюсовых драйверов, так они гораздо приятнее и понятнее.

Даже если взять экзотическую систему, для которой нет компилятора gcc (скорее всего это игровые консоли), то и там стараются C++-фронтэнд иметь. Этим EDG зарабатывает. В худшем случае он может выплюнуть Си-шный код. Так что язык достаточно портируем.

C++ чрезвычайно переусложнён, и его проблемы стараются решать ещё большим нагромождением абстракций, в результате чего и читать, и писать такой код становится больно.

Все последние изменения в стандарты идут как раз в направлении «сделать простое простым». Каждый второй из Комитета выступает за это.

Это надо очень сильно постараться, чтобы сделать ошибку при работе c std.

Справедливости ради: попробуй вставить в вектор во время итерации по нему range-based for 😉.

Тогда, получается, Red Hat осознанно преуменьшает масштаб проблемы, вопросы к ним.

С attribute((cleanup(…))) - не чем угодно.

И тем не менее, я могу собрать библиотеку актуальным gcc, а использовать её в проекте, собираемом актуальным clang — и ничего не сломается, как при переходе на g++ 5.

Это значит, что на предметную область понимания останется меньше, ибо ресурсы разработчика небезграничны

Если для эффективного решения задачи требуется понимание происходящего под капотом, то на C потребуется как раз меньше времени тратить на разбор абстракций, нежели на C++.

Нет так.

other Linux distributions are certainly vulnerable, and probably exploitable

PoC-эксплойти для RHEL (пока) нет. А RH говорит только про свой.

Новые серьезные уязвимости в ядре Linux и systemd

И эти рукожопы ещё критикуют JavaScript

https://gcc.godbolt.org/z/odxsTzWWE

Это миф. extern «C» как раз означает «стабильное ABI» (то же самое, что всякие JNI, «Platform», FFE и прочее). Это часть языка C++.

Вот только это стабильный C ABI.

И еще: в «толстом» интерфейсе гораздо легче работать - можно вернуть вектор, можно бросить исключение.

…Можно создавать копии в памяти на каждый чих (см. причины появления std::string_view), можно во вложенном for создавать объекты итератора на каждой итерации — много что можно делать, мысля исключительно абстракциями и не понимая, как все эти конструкции работают «под капотом».

На практике или же весь дистрибьютив собирается одним компилятором

Как долго вы профессионально пишете на C++?

Ты про массивы переменной длины на стеке?

Не только. Например:

enum {
    ENUM_ONE,
    ENUM_TWO
};

// Designated array initializers в C++ нет
// Поддерживаются g++ как расширение c-style initializers
static char const *const _g_messages[] = {
    [ENUM_ONE] = "Hello",
    [ENUM_TWO] = "World"
};

«маленькое» - это как?

«не сильно огромного» ≠ «маленького».

Кстати, про Embedded - HAL та еще ужасная абстракция на C

С этим не могу не согласиться.

Если для эффективного решения задачи требуется понимание происходящего под капотом

… то на плюсах пишут такой же код без толстых абстракций. А если не требуется - то с ними. Наличие выбора лучше чем отсутствие.

Вот только это стабильный C ABI.

Ага. Mangling, calling convention… Есть Pascal (Windows API), есть (был?) __fastcall. Я специально привел пример, что «стабильный C ABI» работает во многих языках, не только в C++. Что не делает язык C лучше.

Можно создавать копии в памяти на каждый чих

Точно также, как в C поотстреливать себе все нафиг. Если мы все еще обсуждаем мое утверждение «я не вижу смысла писать на C / приделывать к нему расширения».

К сожалению или счастью, но многое в C++ спроектировано так, что лучше делать неоптимально, чем некорректно. Поэтому да, забыл & у параметра и будут делаться копии на каждый вызов. Но в C приходится постоянно следить за тем, кому принадлежит память. А это ИМХО гораздо мутронее.

Как долго вы профессионально пишете на C++?

По трудовой книжке с 2005.

…Designated array initializers…

Интересно, спасибо. В C++ для конкретно этого примера или сразу std::map с initializer list, или просто массив, а в конце проверить, что размер совпадает через static_assert.

Я вот еще подумал. После такого доверие к коду systemd наоборот, поднялось. Если разобраться - изначально Лёня улучшал обработку ошибок, что само по себе хорошо.

Косяк нашелся статическим анализатором - «аллоцировать на стеке буффер ранее неизвестного размера - плохо». То есть на код смотрят, и может даже не столько ложноположительных, что что-то нашли.

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

Что-то у меня обе ссылки не открываются.

checked_div спасут отца русской демократии.

Можешь на Debian почитать:

https://www.debian.org/security/2021/dsa-4941

https://www.debian.org/security/2021/dsa-4942

die перехватывается с помощью eval. Что, никогда исключения в перле не делал?

Дырявый Си опять в своём репертуаре. А C++ они использовать не хотят.

Там же один из багов из-за конвертации size_t в int. C++ в этой части полностью по стопам С идет.

Внезапное падение программы разумней?

Безусловно. Внезапное падение программы это прекрасно. Куда лучше, чем неправильный результат или уязвимость.

…не считая того, что panic! вызывается на всякую чушь.

Не вызывается.

Ну раз так, то, наверное, и драйвер в ядро приняли с паникой, и не пришлось std переписывать?

Да. Код на Rust по прежнему может паниковать, например в упомянутых выше случаях деления на ноль или выхода за пределы массива.

Единственная причина, по которой С++ не прошёл в ядро, это предпочтения Линуса

Его недавно опять спросили про C++ и он опять ответил

The point is, C++ really has some fundamental problems. Yes, you can work around them, but it doesn’t change the fact that it doesn’t actually fix any of the issues that make C problematic.

So no. We’re not switching to a new language that causes pain and offers no actual upsides.

At least the argument is that Rust fixes some of the C safety issues. C++ would not.

Optional приводит к неправильному результату или к уязвимости?

Ну да. А panic перехватывается с помощью catch_unwind. Но в реальных программах и то и другое использовать «не принято».

Второй баг к GNU/Linux отношения вообще не имеет (только к systemd/linux).

А первый баг — точно имеет? Может, он тоже для этой мастдайки убогой, а в vanilla его и нет?

Сейчас уже на основе линукса аж три направления дистров есть: GNU/Linux (гента, девуан, артикс и т.п.), nongnu/Linux (некоторые упоротые дистры, где, как и в упоротых бздях выкинули GNU) и systemd/Linux (красношапка, бубунта и прочая мастдайка).

Optional на такие базовые операторы приводит к тому, что языком никто не пользуется.

А, ну то есть ему ежовые рукавицы нужны встроенные в язык, чтобы в принципе пошевелиться было нельзя. Что ж…

С другой стороны, утверждение «The point is, C++ really has some fundamental problems.» Неплохо бы раскрыть. Хотя зная Линуса, он далеко не эксперт по плюсам, поэтому чего его слушать. У него моск сломан, вот все боль и доставляет.

Там же один из багов из-за конвертации size_t в int.

Haiku идёт по пути отказа от стандартных числовых типов и использует [u]int(8|16|32|64).

Неплохо бы раскрыть

• https://lore.kernel.org/ksummit/CAHk-=wiwZWAo_Ki587FD2BrAQVK71TBN=uKimdBf1Pxg3=+nTw@mail.gmail.com/
• https://lore.kernel.org/ksummit/CAHk-=wjYGDtLafGB6wabjZCyPUiTJSda0c8h5+_8BeFNdCdrNg@mail.gmail.com/

Напротив, на перле это стандартная практика.

Ооо… спасибо. Вот это он упорот 🤦‍♂️.

but it used to be the case that you couldn’t sanely even split a member function into multiple functions to make it easier to read

Чувак живёт вообще в какой-то феерической параллельной реальности. Или же в 80х. Не знаю, что у него там не работало, что такая детская травма на всю жизнь.

Чувак живёт вообще в какой-то феерической параллельной реальности. Или же в 80х. Не знаю, что у него там не работало, что такая детская травма на всю жизнь.

А разве он неправ? Как можно разбить метод класса на несколько вспомогательных функций не меняя .hpp?

Лол, што? А как он разбивает функцию и не меняет .h? Зато в коде полный бардак, не поймёшь, что к чему относится и как.

Это ОК, когда все поддерживаемые платформы одинаковой разрядности. А в кроссплатформенном коде с поддержкой и 32бит и 64 что делать?

А в кроссплатформенном коде с поддержкой и 32бит и 64 что делать?

addr_t/size_t там где это надо.

Конечно же неправ.

Во-первых то, что «все - класс и метод» устарело лет 15-20 назад. Сейчас классы очень маленькие. Минимально под raii / управление ресурсами. Остальное - внешними алгоритмами.

Наследование максимум 1 уровень. Примерно тот случай, когда драйвер реализует интерфейс (его колхозная структура с кучей указателей на функции).

Почти все функциональное.

Справедливости ради, в плюсах никак не могут определиться с signed/unsigned для размеров. И в либах 50/50.. .

Как-то так:

.hpp

struct C {
    void member();
};

.cpp, было

void C::member() {
    // портянка
}

.cpp, стало

static void member_helper_1() {
    // половина портянки
}

static void member_helper_2() {
    // половина портянки
}

void C::member() {
    member_helper_1();
    member_helper_2();
}

Не говоря уже про С++11 и далее, где есть лямбды.

Зачем напрямую искажать информацию?

Не «зачем» а почему. Лжецам не нужно причин чтобы лгать: это просто часть натуры.

Ваш отец диавол; и вы хотите исполнять похоти отца вашего. Он был человекоубийца от начала и не устоял в истине, ибо нет в нем истины. Когда говорит он ложь, говорит свое, ибо он лжец и отец лжи.

Тем не менее за их ложью всегда есть цель. Другое дело что они не всегда ее знают. Как вол, повинующийся морковке на шесте погонщика или его хлысту, редко знает конечную точку своего маршрута.

Индуцируя к родству с дьяволом а потом дедуцируя обратно, можно уверенно заключить, что автор симпатизирует systemd. Ибо все сыны дьявола ему симпатизируют; ибо он – творение Поттеринга подлеца, и миссия у него подлая, и суть его – ложь, от средств промушена до конечной цели.

Либо об этом же можно заключить напрямую, – из желания автора поставить systemd-проблемы рядом с проблемами кернела, – чтобы таковым соседством

1. по возможности купировать и предвосхитить претензии к троянскому коню тысячелетия. Мол «а у них негров линчуют»

2. символизировать этим сравнительную роль ядра и паразитического новообразования типа «большая ответственность порождает большие проблемы» – здесь пришла пора напомнить, что троян под видом «инита» внедрявшийся в систему, изначально не претендовал на ту «ответственность», которую теперь ему вдруг ставят в заслугу. Он паразитически, воровским манером, подползом и подкрадом, захватил область ответственности, а не был зван и прошен; и в этой области он решает лишь те проблемы, которые сам же и создает, но создает проблем всегда немножко больше.

3. ставя рядом, – в рамках одной новости, – systemd и ядро, автор пытается абсолютную ненужность выдать за совершенную необходимость; паразита искующего захватить контроль над OS выдает за со-основу-основ GNU/Linux, – и это короткий индуктивный путь до родства (и непроизвольного сотрудничества) автора с дьяволом. Ибо сие действие напрямую преследует одну из первоцелей Поттеринга, и прям «удивительно», на сколько казалось бы далекие от RedHat обыватели хорошо понимают глубинные мотивы Поттеринга, и на сколько эффективно прилагают усилия для реализации его устремлений. – На самом деле это проще всего объясняется (Оккам доволен) существованием некого единого диктатора воли в обоих случаях… И мы не нуждаемся в том, чтобы перечислять здесь его имена.. В треде изначально пахло серой.

4. Аминь.