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

ну допустим. Но это все равно не решает проблемы целочисленного переполнения. Ни C, ни C++ никак не обнаруживают переполнение как ошибку, а на этапе компиляции обнаруживаются только самые явные ошибки. Даже Раст, который такой весь из себя безопасный, кидает панику только в отладочном бинаре, в релизе молча проглатывает (вернее делает two’s complement wrapping). По-хорошему надо при каждом переполнении кидать исключение и обрабатывать его явно. Но кому это надо, в каждой васянской программе…

У хелперов не будет доступа к закрытым членам. Так что следующий шаг - отказываемся от private/protected.

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

системдя - баг на баге и багом погоняет

static void member_helper_1(C *that) {
}

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

Привет, JavaScript! var that = this;

У хелперов не будет доступа к закрытым членам.

Для этого вроде бы давно придумали шаблон Pimpl. Но тогда появляется лишний указатель.

«Haiku идёт по пути отказа от стандартных числовых типов и использует [u]int(8|16|32|64).» Да причем тут хайку, смотрите другие системы, это нормальный путь любого проекта, ядро венды, UEFI и многие другие, UINTN и PHYSICAL_ADDRESS где нужно. В линугсе тоже делали попытку с u8/s8.., где то есть где то нет, потому что стиль кода такой. UEFI, кстати, отличный пример реализации действительно модульной системы на Си, сделанной по уму и разумеется кроссплатформенной. В линупсе же ацкий ад экспорты символов вместо интерфейсов, int long и прочее. Автор делал пускалку для bash то и получил, это раздутое экзоядро без вменяемой архитектуры и хорошего стиля кодирования.

Надо добавить новый using members aClassVar;

static void member_helper_1(C *that) {
    using members *that;
    method1(); // (*that).method1();
}

И сделать синтаксический сахар для методов, который автоматом вставляет этот using для ‘*this’

И, вообще, унифицировать этот зоопарк using’ов до «with»

Не сработает. Из хелпера не будет доступа к protected/private полям и методам.

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

А вот не надо мешать «интерфейс» и «реализацию», если это важно.

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

И реализуешь/наследуешься/или-другим-способом.

И какая разница? Класс реализации всё равно надо будет открыть в .hpp.

Pimpl. Но тогда появляется лишний указатель.

Хуже: появляется лишняя аллокация и лишний уровень косвенного обращения. Линус сказал бы про это много хорошего.

Класс реализации всё равно надо будет открыть в .hpp.

Нет, если класс реализации только «реализует». Ах да, первый подводный камень - нужна «фабрика по выпуску изделий с таким интерфейсом».

необходимые член-данные можно передавать по ссылке

to make it easier to read

Первоначальная цель начинает блекнуть. Скорее, я бы действительно задумался о том чтобы делать открытые структуры, и сишникам привычнее.

С другой стороны, чем так страшны хелперы в хедере?

Ах, слава Богу! Ты жив! А я-то думал ты умер, раз не ответил на это А я-то распереживался: на кого бы ты нас, юродивых, тогда оставил!

Но по факту обе уязвимости это следствие проблем ядра - скорей бы

Ога, скорей бы! – Когда они вообще выкинут это дырявое ядро из системы, и останется тольк один кавайный systemd? – Об этом чаешь? Если тебе не терпится до этих событий, то кочуй прямиком в форумы Windows – они тебе послужат машиной времени, чтобы ты увидел свой systemd через пяток лет: там вообще нет ядра и сменяемых обвесов, один сплошной systemd – оторви кусок и гавкнет все.

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

Молодцы, конечно, разработчики systemd что всё-таки шлёпнули заглушку на косяк в ядре.

«Разработчики» Андроида лучше поступили. Они заглушку на юзера шлепнули:

цалуй в завалу на кормовой отсек, юзер! Незачем тебе рут-права!

Но ты не отчаивайся. Дойдет прогресс и до тебя: в будущем systemd тоже будет наглухо застрахован и от ошибок в дырявом ядре linux, и от недалекого пользователя защищен: при любой непонятной ситуации будет посылать «к администратору», как оно в винде принято. А рут-права в винде бесполезны: если ты не разработчик винды, то твоей квалификации не хватит что-то там всерьез изменить даже с рут-правами. При той геометрической прогрессии, в которой растет избыточная сложность и монолитность systemd/linux – вскоре его (тобишь тебя) ждет та же судьба. Так что ✩✶✮РАДУЙСЯ!✮✶✩ Пиу!

Документированность systemd дистров уже сегодня должна радовать виндолюбов: документация объясняет исключительно только то, как хорош systemd и как ловко он делает свою работу. И больше ничего. – Я, помнится, ради прикола глянул man init, и другие маны в systemd/linux, и увидал в целом то, о чем всю жизнь пишут в справке винды: «о вас позаботятся». Вот тогда внутренний голос и шепнул мне

бягите, хлопцы!

на кого бы ты нас, юродивых, тогда оставил

О, у тебя уже и раздвоение личности началось?

А если серьезно, то ты меня просто расстраиваешь.

Мерси, польщён - всегда приятно когда у идиотов подгорает от моих скромных реплик.

застрахован и от ошибок в дырявом ядре linux

Для того чтобы понять почему это невозможно надо обладать элементарными знаниями архитектуры ОС. Так что тебе - не судьба.

Если ты говоришь «линукс» на специализированном ресурсе, полном технических специалистов

Тщеславный школотрон детектед. :))
Мальчик, ты когда себя возомнил «техническим специалистом»? С каких это пор ты, такой специалист, стал путать Линукс и ядро? Остынь, отрок! Твой снобизм смешон, иди лучше мамке посуду помой.

Линукс - всегда понятно, про какой «линукс» речь из контекста. Если ты эти контексты путаешь, ты не «специалист», а говно на палочке.

> С каких это пор ты, такой специалист, стал путать Линукс и ядро?

Действительно, как можно путать такие разные вещи

ставя рядом, – в рамках одной новости, – systemd и ядро, автор пытается абсолютную ненужность выдать за совершенную необходимость

«Отлить в мраморе!!» Сустемды - аццкая ТВАРЬение, даже непонятно, как лемминги позволили этой параше занять место в исходниках. (ну, примерно как сейчас с масками) Нас мало, но мы в тельняшках! И я на полном серьёзе буду противостоять любому «сустемды» решению.

Не сработает. Из хелпера не будет доступа к protected/private полям и методам.

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

Линус сказал бы про это много хорошего.

Ну то есть мы тут разыграли по-ролям сценку из головы Линуса «почему C++ г..о» и согласились с ним.

Он прав что ли?! )))

Класс реализации всё равно надо будет открыть в .hpp.

Не обязательно. Но нужно спрятать конструкторы и вместо них дать фабрику (фабричный метод). Из негативного тут то что скорее всего придётся добавить виртуальный деструктор, и «утяжелить» это всё виртуальной таблицей.

Ты воду не баламуть. Какой pimpl? Его в 90% случаев не нужен. Это из той же эпохи, от которой у Линуса травма.

В С++ можно делать все что же с функциям, что и он в С делает. Только возможностей гораздо больше - type safety, шаблоны и inline вместо макросов.

«С с классами, действительно, ну нужен».

Предлагаю объединить данные уязвимости и просвоить им код CVE-2021-36934 :D

Линус сказал бы про это много хорошего.

Да кому какая разница что он сказал бы? Он неосилятор, который пытался мультитред volatile’ом синхронизировать и истерил чёй-то у него всё падает. До тех пор пока разрабы gcc не объяснили ему кто он.

А вот интересно, как он собирается без этого обойтись в С? И при этом сохранять совместимость. Судя по тому, как меняются некоторые вещи в ядре, то частенько к структурам прикручиваются функции потому, что прямой доступ к полям в какой-то момент разработчикам надоел. Так что структура + функции = почти ООП.

ООП в ядре во весь рост. По крайней мере был в 2006, когда я драйвер пытался писать.

Наколхоженный vtable - структура, которую драйвер заполняет указателями на функции, фабрика, которая возвращает эту структуру, динамически аллоцированный pData…

Какой pimpl? Его в 90% случаев не нужен.

Простите, я сам на С++ последний раз больше 10-ти лет назад писал. С++11 застал только под названием C++0x. Могу не знать последних новостей. Но вот посмотрел в код Qt6 и увидел там всё тот же pimpl.

type safety

Ага. А вот и свежий пример type safety в C++.

Да кому какая разница что он сказал бы?

Ну конкретно здесь он был бы прав. На ровном месте терять в производительности – так себе затея даже для юзерспейса.

Но вот посмотрел в код Qt6 и увидел там всё тот же pimpl.

Qt это не образец плюсовой библиотеки во-первых, а во-вторых, им очень важна abi compatibility.

Часть классов у них cow, что сейчас больше фу-фу-фу, но у них по историческим причинам или из-за предметной области есть.

Ага. А вот и свежий пример type safety в C++.

Это наследие С. Integer promotion. Он может и не так по кокохам настучать…

Но с этим борются, например explicit bool.

Хуже: появляется лишняя аллокация и лишний уровень косвенного обращения. Линус сказал бы про это много хорошего.

Интересно послушать его мнение на эту же тему но про Rust, в котором похожая конструкция Box<dyn Trait> не создаёт косвенного обращения, но удваивает размер указателя.

Qt это не образец плюсовой библиотеки

Мне казалось иначе (сужу по ЛОРу гы-гы). Можно пример хорошей, современной библиотеки? Ещё лучше, конкретный пример подхода к полиморфизму.

Это наследие С

Возвращаясь к аргументам Линуса. Он об этом примерно и говорит. Что, мол, С++ не избавляет от проблем из С, но и добавляет свои.

Лично я считаю его мнение спорным и мне больше по-душе прагматизм разработчиков GCC, перешедшим на подмножество С++.

Но то, что работает в user space не всегда работает в ядре. И Линус имеет право на странности в этой части.

Ядро Линукс не святая святых, а устаревшая блотварь. Все, что в ней осталось ценного, это драйвера.

Системда рак, который скоро доест гну.

Ну конкретно здесь он был бы прав.

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

А по теме - ты просто повторяешь за кем-то. Во первых, там эта аллокация ни на какую производительность не влияет - это древний миф «аллокация - это медленно». Во вторых, если у тебя такой объект пересоздаётся множество раз в секунду, вместо opaque pointer(aka pointer to implementation) делают opaque storage(aka storage for implementation) и получают ровно тот же стабильный abi. На посмотри, возможно пригодится:

.hpp:

class some {
  public:
    some();
    some(const some&);
    some& operator=(const some&);
    ~some();
  private:
    alignas(max_align_t) char storage[200];
};

.cpp:

struct some_impl {
 ...
};

some::some() { new(&storage) some_impl{...}; }
some::some(const some&) { ... }
some& some::operator=(const some&) { ... }
some::~some() {
  static_assert(sizeof(storage) >= sizeof(some_impl));
  launder((some_impl*)storage)->~some_impl();
}

Всё, дальше с some_impl в cpp работаешь. Как размер превысит 200, увеличиваешь его вместе с мажорной версией.

Самое главное здесь - это разговоры про pimpl в контексте c++, хотя в c используются те же самые техники.

Попробуй это переписать на кресты без alloca

Кстати, с чего это такое требование?

Вот-вот. Это же касается gtk. Используют принципы ООП по полной, но менее удобными средствами.

launder

Оо… Вот это та самая мифическая функция, которая никому кроме компилятора не нужна!

Можно пример хорошей, современной библиотеки?

Всегда был boost. Ну и стандартная библиотека (кроме легаси из стримов и локали).

Я сам QT считаю одной из лучших библиотек для GUI. Но С++ у них специфичный. Даже есть (была?) доп. тулза в виде moc.

Я сам QT считаю одной из лучших библиотек для GUI. Но С++ у них специфичный. Даже есть (была?) доп. тулза в виде moc.

Там дело не в специфичности, а во времени создания этой библиотеки - 94-й, по-моему. Исключения ещё физически не было, например(ну то есть они в том же 94 появились в C++).

Оо… Вот это та самая мифическая функция, которая никому кроме компилятора не нужна!

Оо… Вот это тот самый идиотский комментарий, который никому кроме его автора не нужен!

Сишников уже и траллить не надо, они рвутся уже при ВОЗМОЖНОСТИ упоминания раста.

Чушь. Осильте соответствующую страницу на cppreference и не позорьтесь.

Я про launder отсюда узнал (давно еще натыкался): https://miyuki.github.io/2016/10/21/std-launder.html

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

Don’t ask. If you’re not one of the 5 or so people in the world who already know what this is, you don’t want or need to know.

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

Кстати, с чего это такое требование?

В Новые серьезные уязвимости в ядре Linux и systemd (комментарий) в ответ на «Как будто С++ запрещает использовать alloca/strdupa. » ты ответил «В C++ есть более удобные способы выбирать дёргать память со стека или с хипа в зависимости от запрашиваемого размера.»

Вот я и хотел посмотреть на эти «более удобные способы» для выделения на стеке. Более удобных способов в C++ без alloca я что-то не увидел, у тебя в примере было выделение фиксированного буфера на стеке и его использование, а это совсем не то, что продемонстрировал я. Кстати через рекурсию еще кое-что можно сделать, но удобным такой метод я б не называл.

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

Не поверишь, но в C также нет стандартного ABI. И да, даже между компиляторами оно отличается src::f => bin::{ f(gcc, clang), _f(mcc) }. Тебе следует подучить матчасть.

Остальное после такого можно не читать.

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

Допустим, вначале можно использовать alloca(), столько-то раз его вызвать для добавления в список, но при превышении определенного порога, выделять дальше через malloc(), чтоб не тратить много памяти на стеке. Если использовать буфер фиксированного размера на стеке, как в твоем примере, и при полном заполнении этого буфера переключаться на malloc(), этот буфер часто будет оказываться недозаполненным, что не есть хорошо. Довыделить память на стеке без alloca() можно только через рекурсию, и я бы не назвал это удобным, стек при таком использовании будет почти наверняка сильнее расходоваться, чем если бы использовалась alloca()

Код прошел ревью. Проблема в тех, кто его проводил, а не в С.

Ну да, ублюдочный синтаксис языка тут не при чем:

https://www.cnews.ru/news/top/2021-07-22_vladeltsy_hrombukov_ostalis

Тяжелое наследие сишечки до сих пор парит мозг. И уже в плюсах в стандарте с начала века закреплено: пользуйте and/or/not и не ошибётесть, но нет, мы будем выплясывать с &&/||/! а потом искать баги:

https://filearchive.cnews.ru/img/news/2021/07/22/chromeoscommit.png

Не для этого, ты некомпетентен.

Довыделить память на стеке без alloca() можно только через рекурсию

😱

И они не менее, исправленная версия аллоцирует в куче. Так что не надо про performance и прочее. Особенно библиотечная функция не должна так делать, т.к. никогда не знаешь, столько у тебя стека: ты можешь уже в конце рекурсии работать, или в треде с уменьшенным стеком. Куча в этом плане более предсказуемая.

У меня есть стойкое ощущение, что alloca нужен лишь для того, чтобы избежать ручного освобождения памяти. Хотя, как выясняется, в gcc (и скорее всего clang) есть расширения, которые это автоматизируют. То есть тут только ради вопрос portability.

Схема с фиксированным буфером на стеке - это скорее small object optimization. Сейчас это стандарт для std::string.