В ядре Linux в коде обработки ограничений rlimit в разных пространствах имён идентификаторов пользователей (user namespaces) выявлена уязвимость (CVE-2022-24122), позволяющая повысить свои привилегии в системе. Проблема проявляется начиная с ядра Linux 5.14 и будет устранена в обновлениях 5.16.5 и 5.15.19. Стабильные ветки Debian, Ubuntu, SUSE/openSUSE и RHEL проблема не затрагивает, но проявляется в свежих ядрах Fedora и Arch Linux...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56610
Ну что, кто-нибудь ещё скажет что-нибудь после такого о превосходстве Сишников? То-то же! Раст всем голова.
Я тебя даже плюсанул. Вполне неплохой наброс.
Такой неплохой наброс можно писать под каждой новостью про очередную сишную дыру. То есть минимум раз день.
И это хорошо!Приятно начинать день с чашечки вкусного кофе и приятных набросов на опеннете.
После чего, наконец проснувшись подняв себе настроение, можно и за кодинг на сишечке браться.
С мыслью "этому миру нужно больше дыр".
До слёз ;)
Говори за себя, дыра.
Головка.
Вертеть?
"Безопасный язык" только предотвращает ситуации, от которых всё падает.
Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код.
И так как мышление становится пережитком прошлого -- как легко видеть из ситуации с растохайпом -- то бэкдоры служить будут сильно дольше, а внедрение их обойдётся значительно дешевле.Поэтому раст выгоден.
Поэтому хайп будет нарастать.
> Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код.Это значит что и у Си после вычесывания (удачи!) типичных ошибок переполнениями и т.п. (которых 70%), допущенных наСильниками, останется 30% ошибок, "для выявления которых придётся больше думать и серъёзнее анализировать код". Только еще хуже - в типичной Си-шной многопоточке еще дополнительный ворох нетривиальных проблем подбрасывается (всякие рэйс-кондишоны), в отличие от типичной многопоточки Раста с его понятием владения, по дефолту взаимодействием посредством передачи сообщений и пр. (хотя на Расте тоже можно при желании в сишном стиле написать, с разделяемыми между потоками данными и объектами синхронизации и поиметь тот же ворох проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").
> (хотя на
> Расте тоже можно при желании в сишном стиле написать, с разделяемыми
> между потоками данными и объектами синхронизации и поиметь тот же ворох
> проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").Ну вот! Видишь! И зачем тогда нужен этот ваш Раст? * пошел выкручивать из машины ненужные подушки и ремни безопасности вместе со смузихлебными ESC и ABS *
так ведь "при желании"! Если есть желание "самоубиться" - пжалста! Но только наСильник будет пытаться упорно применять техники из Си в Расте.
Для сишечки тоже есть умные указатели.
Например, https://github.com/Snaipe/libcsptrНо в ядре их не используют.
Умные указатели для неумных людей.
Умные люди, видимо, получают use-after-free уязвимости
На раст уже редох написали. Ага, дайте две.
Ну это опционально, а нужно чтобы принудительно было, чтобы нельзя было забыть что-то где-то. Максимум компиляторногг контроля
Не компиляторного. А со стороны непрерывной интеграции.
Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль. Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход
> Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль.Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда.
Я бы вообще просто по фразе "CI - костыль" выпинывал из профессии назад в то ПТУ, где оного персонажа учили, на второй год.
> Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход
Это корректный код?
float sine(float x)
{
return cos(x);
}а это?
float enis(float x)
{
return cos(x);
}Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?
> Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлдаДа понятно дело, но ведь это обусловлено несовершенствами наших языков
> Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?
По содержательным вещам - пишется спецификация и доказывается. Пример - seL4
Что же касается темы Си, Раста и всего такого - если можно вложить доп проверки, почему не вложить? Си пропустит такой кусок кода
int * x;
if <somecond> {
int tmp = 1;
x = &tmp;
}хотя он явно не корректен и поймать это легко. Что Раст и делает и не допускает такой код
> Да понятно дело, но ведь это обусловлено несовершенствами наших языковБерите шире - Вселенной. И это не стеб и не сарказм.
> если можно вложить доп проверки, почему не вложить?
Если при этом не ломать работающее, конечно же. Или вы так не думаете?
> Что Раст и делает и не допускает такой код
За цену этого "не допускает" не хотите поговорить? Ну то-есть как бы за все надо платить, не так ли? Или не важно?
Я вот, например, от такого кода очень легко избавлюсь с помощью специального инструментария, называемого статическими анализаторами. При этом у меня остается свобода написания высокоскоростного кода.
А у вас не остается.
Вот если я предложу ради безопасности вашего ребенка (машина не собьет, маньяк не зарежет) поместить его навечно в дурку - вы согласитесь? Я думаю - нет.
Вот и тут так же.
> При этом у меня остается свобода написания высокоскоростного кода.
> А у вас не остается.Почему?
Абстрактные рассуждения про цену звучат, конечно, классно, но где конкретные примеры того, что Раст даёт сильную просадку по производительности именно из-за запрета того или иного кода?
> где конкретные примеры того, что Раст даёт сильную просадку по производительностиУзковато мыслите. Добавьте сюда "цена разработки" и "цена сопровождения".
Так снижается же цена сопровождения наоборот, по сравнению с "опасной процедурой на встроенном ассемблере, экономящей 50-100 раз время выполнения"
Цена чего? Покажи пример большого оверхеда.Ты можешь завернуть критический участок в ансейф, написать "мамкой клянусь тут нет race" и говнокодить как хочешь. Просто тебе попросят это доказать.
Можешь сделать вставку на асме. Делается так же элементарно (и тоже разумеется unsafe)Если цена отсутствия всяких хардблидов или получений рута - отправить на пенсию пару старперов-неосиляторов, то это не большая цена.
Тебя не ограничивают ни в чем.
> Цена чего?Разработки и сопровождения.
> Ты можешь завернуть критический участок в ансейф ...
> ... Просто тебе попросят это доказать. ...
> ... Тебя не ограничивают ни в чем.у вас, растоманов, совсем каша в голове. Я так и не понял - раст не дает говнокодить или никак не препятствует? И чем это отличается от С, где точно так же можно говнокодить, а можно и нет.
Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе?
В чем плюс то? В том, что можно мозги не включать?
> отправить на пенсию пару старперов-неосиляторов
Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании не получится (разве что уже когда маразм придет).
> Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе?Ниже Ordu писал о проблеме - проблема в семантике Си, в которой очень многое, с теми же умными указателями, возможно выполнять только в рантайме вместо компайл тайма. Если бы в Си была куда строже семантика, с куда более строгим отношением к UB, тогда дело иное. Вот потому анализатор и должен быть в компиляторе, и язык должен иметь куда более строгое отношение к UB и подобной ерундистике
Ну и где примеры высокой цены "Разработки и сопровождения" на расте?
То что научиться писать на Си можно ̶л̶ю̶б̶у̶ю̶ ̶о̶б̶е̶з̶ь̶я̶н̶у̶ студента пту мы знаем. А вот найти крутого Си программера - ой какая проблема, потому что даже мЭтры из ядра линя лажают на таких простых вещах.
А у раста входной порог выше - не каждый сишник осилит ownership и borrowing. Зато потом существенно меньше багов с памятью.> Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе?
Ну сменишь ты компилятор, даже заставишь это даже компилироваться, а потом внезапно окажется что его разрабы по-другому реализовали серые места стандарта и твой результат изменился на противоположный. Прекрасно ведь!
А плюс в том, что тебе на этапе компиляции рассчитывается владение и заставляют или исправить баги, или явно сообщить что ты гарантируешь это. Раст не дает говнокодить втихаря. В отличие от...
Есть прекрасная вещь - Clang Static Analyzer, который на минуточку является часть clang. И что?
> Написал человек, не понимающий разницу между компилятором и анализатором.
Фиг его знает где ты это прочел, но спишем уже на старческий маразм.
> Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж
> нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании
> не получится (разве что уже когда маразм придет).-
1.2 The Structure of a Compiler1.2.1 Lexical Analysis
1.2.2 Syntax Analysis
1.2.3 Semantic Analysiss 608
Most global optimizations are based on data-flow analyses,
hich are algorithms to gather
information about a program.
The results of data-flow analyses all have the same form:
for each instruction in the program, they specify some
property that must hold every time that instruction is executed.
...
For example, a constant-propagation analysis computes,
for each point in the program, and for each variable
used by the program, whether that variable has a unique
constant value ...И правда, кто такие
"Alfred V. Aho, Columbia University
Monica S. Lam, Stanford University
Ravi Sethi, Avaya
Jeffrey D. Ullman"
из "Compilers Principles, Techniques, & Tools", да супротив Урри, "Оупеннут Юниверсити"?!
Когда закончились аргументы, побежим размахивать "авторитетами".Слив засчитан, молодец.
Когда Урри опять с умным видом пyкнул в лужу, демонстрируя незнание азов и _общепринятой_ терминологии и побежал размахивать "сливом".
не обязательно. логика простая - чем раньше обнаружена ошибка, тем ее дешевле править. так просто дешевле их править, но при строгом ci тоже вполне можно ловить большую часть. и на хрусте тоже надо писать тесты
Не спорю, но чем больше у нас проверок на ранних этапах, тем лучше. Надеяться только на CI - уже попахивает костылищем
ну нафиг, если они такие умные то рано или поздно выйдут из под контроля и образуют скайнет
"Ты чё, умный дох*я? А, указатель? Память есть? А если найду?"
память как бы не его, он на неё показать токмо и может
> память как бы не его, он на неё показать токмо и можетНу это с какой стороны посмотреть. Умные указатели еще и для того чтобы память не освобождалась несколько раз. Так что можно сказать что указатель данную память забирает на себя.
Там же только uniq_ptr и shared_ptr, причём со всеми граблями C++'овых аналогов, типа "никаких гарантий". Например, uniq_ptr может быть NULL, то есть просто взять и разадресовать его, не проверяя на NULL -- это лишь до первого бага, который положит NULL туда, где NULL быть не должно.Более того, насколько я вижу, эти указатели реализованы на _рантайм_ проверках, и более того эти рантайм проверки должны выполняться клиентским кодом. То есть, не, он может не проверять, и в случае ошибки в коде получит в рантайме разадресацию NULL с вытекающим из неё сегфолтом. Это _динамическая_ типизация в статически типизированном языке. В C++ тоже с этим проблемы вылезают[1]. Более того, если присмотреться[2], то проблема вытекает из свойств C и C++, которые делают невозможной move-семантику с compile-time проверками на то, что значение было перемещено, и поэтому программист, реализуя move constructor _вынужден_ обеспечивать своему типу специальное значение, которое семантически можно описать фразой "value was moved out, nothing to see here, go away", чтобы это значение можно было бы проверить в рантайме. А это означает, что uniq_ptr будет by design иметь значение NULL, и значит что если разадресовывая его ты забыл проверить на NULL, то значит ССЗБ.
[1] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
[2] https://www.thecodedmessage.com/posts/cpp-move/И это фундаментальная проблема, которая делает "умные" указатели бессмысленными в C и C++. Они не столько предотвращают ошибки, сколько снимают часть бойлерплейта, необходимого для того, чтобы избежать ошибок, и таким образом заметают потенциальные проблемы под ковёр, делают их менее заметными. Именно поэтому в ядре использовать uniq_ptr невозможно: в ядре всё в принципе по-возможности делается явным, чтобы было видно что происходит. Ядро пишется на C, и идеология написания кода ядра заточена под C: на компилятор нельзя полагаться, можно полагаться только на себя. Чтобы понять это, я могу порекомендовать Торвальдса, кормящего C++ тролля[3], где его ключевой тезис сводится к:
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.[3] https://harmful.cat-v.org/software/c++/linus
То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app. А подход C++ не работает довольно часто, потому что он не устраняет ни одной проблемы C, он лишь декорирует их кружевами, позволяя в 90% случаев делать вид, что это не баг, а фича. Но в оставшихся 10% тебя ждут те самые infinite amounts of pain. И смарт-поинтеры, реализованные в C, не нужны в ядре по той же самой причине. Они не снимают ни одной проблемы: тебе точно так же придётся своими глазами следить за тем, чтобы не разадресовать нечаянно указатель, который был куда-то перемещён. Сама операция перемещения dst←src, с последующим обнулением src, будет чуть проще записываться, но следить за тем, чтобы не обращаться к src после перемещения ты точно так же будешь глазами. А каждый твой фейл будет приводить к рантайм краху. Это не делает программирование проще: проследить глазами за обнулением src проще, чем за тем, чтобы он потом не использовался.
А если пытаться сделать всё хорошо и статически проверять все эти uniq_ptr, дабы не выносить проверки в рантайм, то:
> if you try to statically detect such situations, you end up with Rust.[4][4] https://www.foonathan.net/2017/09/destructive-move/
Упс. И статические анализаторы не спасут C и C++, потому что эти языки не кодируют в своих API тех допущений, которые необходимы этим API для работы. Теоретически можно было бы API дополнять комментами (примерно как в некоторых динамических языках запиливают статическую типизацию, описывая типы в комментах), но хмм... я не уверен, что это сработает. Теоретически -- да, должно быть возможно, но практически, мы получим две одновременно действующие системы типов, и я подозреваю, это кончится таким уродством и ногу-сломишь-в-этом-коде, что нахрен никому не нужно. Проще лишнюю рантайм проверку вставить, и выкинуть панику если NULL оказался там, где его быть не должно.
Как поставить 100 плюсов?)
Браво за детальный ответ, сударь!
А ещё C++ абстракции не бесплатны.Например инициализация памяти с помощью конструкторов, которые вызывают конструкторы member-членов, которые вызывают ... ну вы поняли.
Вместо того чтобы инициализировать кусок памяти разом и туда запихнуть весь layout структуры.
В Zig отказались от (супер)быстрого pattern-matching. Потому что if else всё равно быстрее (до 10 раз).
И компиляторы не способны в оптимизацию таких случаев как более простые и понятные конструкции.Поэтому до сих пор С быстрее С++.
И, конечно, абстракции С++ текут. Например деструктор (и в нём надо защищаться от exception, использовать try / catch, и ... дальше у Майерса почитать).
Получается лютый говнокод.
Но я как бы и не говорил что умные указатели - серебряная пуля. Любой задаче, само собой, свои решения.Отличный ответ, без сомнения. За исключением некоторых моментов:
> То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app.Это онтосится ко всем языкам и парадигмам программирования без исключений.
> А подход C++ не работает довольно часто,
А вот это совершенно не так. Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого.
> позволяя в 90% случаев делать вид, что это не баг, а фича.
И снова аргумент разбивается о реальность.
>Но я как бы и не говорил что умные указатели - серебряная пуля.Зато ты постоянно говорил, что умные указатели в плюсах - это так же эффективно и круто, как в Раст. Оказалось - нет. А ещё говорил, что сообщество Раст тупое. И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в плюсах, и твоей любимой сишечке на самом деле. Ну и кто тут идиот теперь?
>Это онтосится ко всем языкам и парадигмам программирования без исключений
Я давно заметил, думать и приходить к правильным выводам - не твой конёк. Это никак не относится к низкоуровневым языкам. От слова совсем. Разжевать или сам поймёшь, почему так?
>Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого.
Никто не знает, чего это стоило их авторам. Попадалась статья как-то, где один спец оптимизировал софт на крупной международной бирже. Ему одному в итоге удалось сделать на F# за полгода то, что десяток плюсовиков не могло сделать несколько лет. Скорость реакции софта выросла в несколько раз. Причина тормозов - излишняя сложность плюсов в местах, где нужна была высокая конкурентность вычислений.
> А ещё говорил, что сообщество Раст тупое.Да. И продолжаю это говорить.
А сообщество в каждой новости это подтверждает.
> И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в
> плюсах, и твоей любимой сишечке на самом деле.А ведь ты даже не понял что там написано, правда?
> Ну и кто тут идиот теперь?Ты.
>>Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого.
> Никто не знает, чего это стоило их авторам.Я знаю. Я за свою жизнь поучаствовал в немалом количестве сложнейших проектов на С++, а уже скоро как большую часть этого времени даже составлял сметы и для самих проектов и для их сопровождения.
> Ну и кто тут идиот теперь? #2Ты. #2
> Попадалась статья как-то, где один спец оптимизировал ... за полгода то, что десяток плюсовиков
> не могло сделать несколько лет.Вот. Ты даже не понимаешь что такое "программный продукт" и что нельзя переносить свой опыт хелловорлда на разработку больших сложных вещей. Статья ему попадалась...
> Ну и кто тут идиот теперь? #3
Ты. #3
--
Видишь? Я был прав во всем.
> Да. И продолжаю это говорить.
> А сообщество в каждой новости это подтверждает.Не забывай в зеркало почаще смотреться. Ты гораздо хуже.
>> И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в
>> плюсах, и твоей любимой сишечке на самом деле.
> А ведь ты даже не понял что там написано, правда?Я-то прекрасно понял. Там понимать особо нечего. Рантайм-проверку один типа специалист Урри пытался приравнять проверке на этапе компиляции. Сидиоты, они такие.
> Я знаю. Я за свою жизнь поучаствовал в немалом количестве сложнейших проектов
> на С++,В роли зрителя? Вряд ли это можно считать поводом для гордости.
> а уже скоро как большую часть этого времени даже
> составлял сметы и для самих проектов и для их сопровождения.А, так ты экономист-бухгалтер. С этого и следовало начинать.
То, что ты создавал видимость активной работы, я не сомневаюсь. Но глядя на твои выперды на этом форуме и удручающе незнание предметной области, сильно сомневаюсь, что такая активность была сколь-либо эффективной.
> Вот. Ты даже не понимаешь что такое "программный продукт"
Тебе бы, дурачку, мне рассказывать про программные продукты. Я в этой индустрии уже второй десяток лет работаю с крупными клиентами по всему земному шарику.
> Видишь?
Вижу. Гнать подобных тебе "спецов" подальше из профессии ссаными тряпками.
Ладно крах при разименовывании NULL. Но от "что позволяло добиться выполнения своего кода на уровне ядра." как-то можно принципиально избавиться в таких случаях?
А толку что есть? Их все равно никогда (при жизни Линукса, по крайней мере) не затащат в ядро.
Проект новье (вроде с 2016 года, но не точно). Не обкатано, не проверено. Еще и по MIT License.PS: О, неужели до сишников таки дошло что автоматическое управление памятью это хорошо?
> PS: О, неужели до сишников таки дошло что автоматическое управление памятью это
> хорошо?Сишники, вообще-то, знают когда автоматическое управление памятью хорошо, а когда плохо. Для хорошо у них даже куча реализаций GC есть.
Q. Can I use this on a serious project ?
A. Yes, but as this project has not been widely used, there might be some bugs. Beware!А ещё эта хрень зависит исключительно от одного свойства компилятора gcc, насколько я понял. То есть, для других компиляторов может не работать.
Для растоманов все еще новость, что библиотеки могут быть разными.Я привел один из примеров библиотеки с умными указателями на С. Таких примеров можно найти десятки. Некоторые даже используются во внутренних кухнях больших проектов.
Вон там выше аноним упрекал меня в том, что я утверждаю что сообщество растишек идиоты. Так вот, жизнь каждый раз это подтверждает. Как, например, прямо сейчас.
> user namespaceВторой ebpf
отключается в отличие от, как я понял проблема в очередной раз притянута за уши и в данном случае речь просто об ошибке в ядре из-за недостаточно качественно проведённой работы по рефакторингу
всм? оба отключаются.Я про решетo, половина уязвимостей в ядре - ebpf и userns
P.S. Почему ворд вильтер агрится на "решетo"
как отключить ebpf в актуальном ядре?
> как отключить ebpf в актуальном ядре?# CONFIG_BPF_SYSCALL is not set
# CONFIG_BPF_JIT is not setCONFIG_BPF как я понял ни на что не влияет
Алсо, в актуальном ядре оно запрещено непривелигерованным пользователям
Это не ebpf. В выводе видно на что он влияет, но он тоже не отключается большеCONFIG_BPF=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
# CONFIG_BPF_JIT is not set
CONFIG_HAVE_EBPF_JIT=y
> Это не ebpf.cbpf мертв, не помню удалили его полностью или нет, но всегда используется ebpf
> CONFIG_BPF=y
Инклюдит мейкфайл bpf
> # CONFIG_BPF_SYSCALL is not set
Это оно как раз
> CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
> CONFIG_HAVE_EBPF_JIT=yЭто значит что архитектура поддерживает ebpf jit
> # CONFIG_NETFILTER_XT_MATCH_BPF is not set
> # CONFIG_BPFILTER is not set
> # CONFIG_BPF_JIT is not setЭти забыл, да.
> он тоже не отключается больше
Все норм отключается, и на мастере, и на next, и на 5.16
Раньше можно было убрать любые упоминания(
> как отключить ebpf в актуальном ядре?Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную группу, практически per-appliaction firewall.
А вот для не-рута надо запрещать, да.
> Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную
> группу, практически per-appliaction firewall.Ну не всем и не всегда это требуется
> А вот для не-рута надо запрещать, да.
В принципе, в 5.16 так и сделано по дефолту
> P.S. Почему ворд вильтер агрится на "решетo"Если бы вы увидели список всего, на что агриться это чудо, то вы бы истерично смеялись, потом плакали, потом опять плакали...
Просто примите пожалуйста, что на опеннете правила фильтрации "очень особенные", и не вдавайтесь в подробности и не зацикливайтесь, а то ещё больше будет мнений, что создавали это чудо также "особенные", со своим видением мира!
Проще пользоваться с поправкой на это, чем пытаться вникнуть, разобраться и тем более что-то исправить, даже обсуждение этого ни к чему хорошему не приводит, а нервные клетки не восстанавливаются, разумнее принять и продолжать пользоваться как есть не думая о "красно***ой обезьяне"!
>речь просто об ошибке в ядреВсего-то на всего. Тьфу ерунда.
Если бы кое-кто выполнял работу более аккуратно, этого можно было бы избежать. Или если бы другой кое-кто проследил, что ожидаемая и предсказуемая ошибка не была допущена. Не стоит стигматизировать удобные механизмы из-за банального раздолбайства.
первый.Лет десять уже этой попытке сделать чтоб вот любой юзер был как рут, но не совсем. На пол-шишечки.
Опыт винды (где это даже не считается уязвимостью) ничему не научил. Вернее, научил все тому же - "мне двойное то же самое что тому джентльмену!"
Первый хронологически.
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directoryCONFIG_USER_NS=y
что надо включить?
>Проблема проявляется начиная с ядра Linux 5.14
>linux-image-generic/impish-updates,impish-security,now 5.13.0.27.37 amd64 [установлен, автоматически]
Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого патча и гордится этим.
> Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого
> патча и гордится этим.Актуальные бунту ядра поддерживаются самой канониклой, а вот насколько эта сикурити-поддержка качественная, это уже другой разговор, не нужно ссылаться на то, что ядра бунт уже EOL в kernel.org, что у Debian подобная практика имеется, что у красношляпы.
Я удивлён, что вы про это не знали, или если это такой наброс с вашей стороны, также удивлён, вроде такой сурьёзный мужчина?!
> а вот насколько эта сикурити-поддержка качественнаяМеня смущает тот факт, что патч версия у Анонима (6) до сих пор 0, хотя на кернел.орг последний патч для этой версии был 9. И тут есть два варианта - либо они нарушают версионирование (что плохо), либо они не обновляют патч версии из апстрима (что тоже плохо). В общем, убунтыдебианы сами себе проблем создают, вместо того чтобы использовать LTS с кернел.орг
> вроде такой сурьёзный мужчина?!
Вот это уже обидно было. Был бы я серьёзным - не страдал бы фигнёй на опеннете xD
У убунты ядро всегда версии x.y.0, они много чего в него переносят, не поднимая 0, иначе бы их версия, допустим, 5.13.6 не соответствовала бы настоящей 5.13.6.
Вот и разбиваются доводы Военов АнтиРастового Сопротивления о суровую реальность и кучи уязвимостей.Не могут даже ucount безопасно отрефакторить, отличный язык.
JavaScript получше будет.
А вы спрашиваете, зачем стейбл во времена блидинг эджей.
>use-after-freeпикачу^Wrust - я выбираю тебя!
А C# уже всё, не в моде?
Будето там такого нельзя. При желании тоже можно звать объект после вызова деструктора.
А что не питон?
> продолжали использоваться после освобождения выделенной для них памяти (use-after-free)Захохотал
Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free?Погонять на устройствах, отловить такие баги, часть хотя бы.
Походу дела ядро вообще не тестируют.
Вроде что-то похожее использует в Zig.
> Походу дела ядро вообще не тестируют.Ядро тестируют на пользователях, это официальная позиция корпораций-разработчиков.
> Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free?Для этого нужно прогнать через всевозможные сценарии использования и окружения. Иначе можно и не поймать.
> Redox is a Unix-like Operating System written in RustДа, я тоже посмеялся.
>> Redox is a Unix-like Operating System written in Rust
> Да, я тоже посмеялся.Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого Вторжения"?
>>> Redox is a Unix-like Operating System written in Rust
>> Да, я тоже посмеялся.
> Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают
> раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого
> Вторжения"?
>"Redox is not correct, secure, or documented. It does a lot of things in a cavalier, leave it up to the application, manner. Applications can malloc and forget to free, Redox will not clean this up. Applications can access missing memory or kernel memory, Redox does not care. All applications run in Ring 0, and have all permissions. Some syscalls use vtables that rely on exactly the same struct defintions in userspace as kernel space. Syscalls cannot return values, except by writing them into a passed pointer. Memory allocation is done in the application, and uses a global memory allocation table that applications directly modify. None of its functionality is documented, outside of example source files." -- https://redox-os.org/Гениально, Карл! С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом. А учитывая что этому хелловорду даже CVE присваивать стыдно -- то можно с уверенностью сказать, что редох это флагман безопасности осестроения растаманек. :-D
> С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом.Если не знаете -- это понятно. Но вы не увиливайте: там use-after-free много уже нашли или нет?
Rust-то такого не позволяет. Он просто память не освобождает, потому и нет use-after-free.
В смысле "не освобождает"? Вы про что? Можно так же ссылку на первоисточник? И напомню, что вы сказали про Rust, а не про Redox.
Йохохо, всего два дня прошло с предыдущей дыры, а тут уже новая подоспела. И опять повышение привилегий, и опять налажали с памятью.
Стабильность признак мастерства!
Растовчане то так не могут, что за неудачники
Янукович & Co?
И снова неймспейсы. Эта музыка будет вечной.
И снова перекидывания фекалиями фанатиков раста и сишечки.Дело не в том, что какой-то из этих языков лучше или хуже, а в том, что ядро Linux — это 30-летний поток монолитного говнокода без какого-либо намёка на продуманную архитектуру и контроля за качеством.
И тут ты такой из-за угла с продуманной архитектурой. Что, нету? Странно.
Растаманьки, скажите, а правда что в расте невозможен use after free по определению? :-)lynx -dump 'https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust' | grep -A1 -B1 'use-after-free' --color
у растенек все течёт, но это безопасно. ведь порчи данных не будет, будет постоянный отказ в обслуживании или автоподрыв ракет
> автоподрыв ракетДа ладно, всё решается избыточностью - запускаем, допустим, пять контейнеров, в каждом из которых независимо крутятся программы управления ракетой, написанные независимыми группами разработчиков на расте, электроне, сиплюсплюсе, петоне и джаво. Сверяем сигналы управления, которые генерируют эти программы. Если, допустим, какой-то контейнер выдал на элерон №1 управляющий сигнал, на N% отличающийся от того, что выдало большинство сервисов, то перезапускаем проштрафившийся сервис, сигналы от остальных усредняем. Если кворума вообще никакого нет, т.е. все пять сервисов выдают сигналы с разбросом более N%, то отключаем нафиг всю эту халабуду и летим как деды летали - на резервном контроллере, запрограммированном на сишечке..
Скорее всего получится ситуация "а вы друзья, как ни садитесь, всё в музыканты не годитесь" и ракета всё-таки полетит на резервном контроллере, запрограммированном на сишечке. Но в пресс-релизах будет только пятикратный кворум, встроенный кубернетес и прочее вот это вот всё. Иначе не получится распиливать.
Теперь будет Rust Kernel за место Linux Kernel xDDDDDDDD
что-то в винде меньше дырок чем находят в linux kernel..
Вы не поверите - у винды исходники закрыты, поэтому приходится страдать и искать уязвимости в отладчиках и дизассемблерах с гораздо меньшей эффективностью, но гораздо более тяжёлыми последствиями. Вероятность того, что найдут zero day, который поставит раком половину планеты, как шифратор Petya через SMB протокол, сильно выше, чем в линуксе.