В вошедшем в состав ядра Linux 6.18 механизме межпроцессного взаимодействия Binder, написанном на языке Rust, устранена уязвимость (CVE-2025-68260). Проблема вызвана состоянием гонки при выполнении операций в блоках unsafe, напрямую работающих с указателями на предыдущий и следующий элементы списка. При успешной эксплуатации уязвимость в Binder ограничивается аварийным завершением и не приводит к повреждению памяти...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64439
> Проблема вызвана состоянием гонки при выполнении операций в блоках unsafeПо идее unsafe должен быть огорожен так, чтобы использование этих блоков в safe коде было безопасно, не?
> По идее unsafe должен быть огорожен такТак ошибка в самом unsafe блоке!
Он как бы unsafe как раз потому, что компилятор не может доказать его валидность.
И если есть проблема - то нужно искать в первую очередь в unsafe блоках, а не по всему поду.
На Rust написано 0.1% Linux, но он генерирует 0.6% ошибок. Это успех!
> генерирует 0.6% ошибокЗа сколько времени?
В ведре за год уже нашли 1.5к ошибок.Вы не хотите работать в ЦИК? Нам нужны такие люди!
Не беспокойтесь, товарищ, мы увеличим безопасность ядра на все 146 процентов!
А сколько всего компонентов в ядре? В статье забыли почему-то написать...
По данным сайта cvedetails.com [1] в ядре линя было 12880 уязвимостей.
0.1% это 12.8 уязвимости.А раст создал всего одну. Т.е. раст безопаснее сишки в 12.8 раз.
Это таки да успех.[1] cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
Так раст в ядре всего около года, а линуксу уже, на минуточку, больше 30 лет.
> Так раст в ядре всего около года, а линуксу уже, на минуточку, больше 30 лет.Именно!
И 0.1% это же от всего, а не от "кода добавленного за период", где 159 уязвимостей.
И это ещё не предел!
>На Rust написано 0.1% Linux, но он генерирует 0.6% ошибок.Это явный оптимизм
Скорее 0,000000000000001% при 0.6% =)
Если на языке не создавать ничего нового - он точно будет самым безопасным!
Переписанцы?.. переписуны.. засланцы.. Эээ.. да ну их в unsafe!
Он как бы unsafe как раз потому, что раст без него не может ничего
А зачем тогда язык, который всегда unsafe?
> Он как бы unsafe как раз потому, что раст без него не может ничего...вызвать в сишном окружении.
А на расте можно делать что-то ещё кроме вызова сишного окружения?
Да
Почему тогда не делают?
Западло с нуля переписывать раздутые библиотеки. Конечно, есть джедаи, которые либы переписывают на Rust или тулзы, как coreutils https://github.com/uutils/coreutils, но это если требуется, можно и с unsafe {} потерпеть.
Хейтерам не угодишь: используем сишные либы — вы ехидничаете "а чё свои не сделаете", пишем свои — гундите, что не нужно. Идите, знаете куда, с такой логикой... читать книги по философии. У вас в голове каша.
Можно. Всё также unsafe, но работаем уже напрямую с железом, не дергая сишное окружение.
Но редокс не взлетело, а пошли юзать сишный линукс.
по идеи надо писать любой код так, что бы всё работало правильно и безопасно хдд. правильно хартман говорит
рецепт "делай хорошо и не делай плохо" - универсальный, пригоден для любого языка программирования и для любой области деятельности вообще.
В ядре пока с этим проблема, потому что сами разработчики ядра не всегда способны сказать как определённые апи правильно использовать, ничего внятнее "делайте как другие делают"
> ничего внятнее "делайте как другие делают"На этом принципе цивилизацию (и не одну!) построили, а тут всего лишь какое-то ядро.
> В ядре пока с этим проблема, потому что сами разработчики ядра не всегда способны сказать как определённые апи правильно использовать, ничего внятнее "делайте как другие делают"Потому как документация быстро устаревает и нет людей, которые хотели поддерживать ее в актуальном состоянии. Ну и "лучшая документация - это исходники". Открыл посмотрел как реализовано и какие параметры как используются - и дал, то что требуется.
> Потому как документация быстро устаревает и нет людей, которые хотели поддерживать ее
> в актуальном состоянии. Ну и "лучшая документация - это исходники". Открыл
> посмотрел как реализовано и какие параметры как используются - и дал,
> то что требуется.Вот только в Rust для того чтобы написать безопасную обвязку над небезопасным кодом - надо чтобы эта безопасная обвязка гарантировала что данные передаваемые небезопасному коду не нарушали его инвариантов - если небезопасный код читает элемент массива N, значит обвязка должна проверить что длина массива как минимум N+1
В ядре над многими функциями сложно сделать безопасную обвязку, потому что всех инвариантов не знает никто, и даже разаботчики на си иногда с этим ошибаются, потому что из C кода эти инварианты не известны
>Вот только в Rust для того чтобы написать безопасную обвязку над небезопасным кодом - надо чтобы эта безопасная обвязка гарантировала что данные передаваемые небезопасному коду не нарушали его инвариантов - если небезопасный код читает элемент массива N, значит обвязка должна проверить что длина массива как минимум N+1Наконец-то кто-то об этом заговорил. А теперь подскажите, как это сделать во время компиляции? Подсказка: я неоднократно писал об этом раньше.
>>Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, написал, что Rust не является панацеей, позволяющей избавиться от всех проблем безопасности, но данный язык действительно помогает защититься от определённого класса уязвимостей.инстант демедж контрол.
Объявлено начало эпохи постоянного падения ядер линукса.
Он в чём-то неправ? Лучше сегфолт или поимение кулхацкером?
Они хотя бы попытались переписать…
Так можно и на Си переписать, зачем Rust, если всё равно гарантий нет.
Логика уровня:
"Зачем вам ремни и подушки если от столкновения с Камазом это не защитит!"Вы случайно не на СИ пишете)?
> Логика уровня:"Зачем вам ремни и подушки если от столкновения с Камазом это не защитит!"
Лигика. Зачем вам ремни если вы только и делаете, что их отстегиваете, что бы вручную в коробку передач залезть, для замены передаточного числа.
> Лигика. Зачем вам ремни если вы только и делаете, что их отстегиваете, что бы вручную в коробку передач залезть, для замены передаточного числа.Ну так нет еще нормальной коробки.
Зато простое открытие двери не отрезает водителю ноги.Мне не нравятся аналогии с автомобилями, тк я езжу на метро.
Давайте лучше сравнивать с унитазами?
Ну так вот - унитаз локализует овно в квартире.
Как и unsafe в коде.
Не обязательно. Человеческая опа агрегат широких возможностей, можно выстрелить мимо, сидя на нем.
> Зачем вам ремни если вы только и делаете, что их отстегиваетеЛожная аналогия. Процент ансейф кода в ядре сильно меньше 5. Процент ансейф кода в юзерспейсе сильно меньше 1.
Процент ансейф кода в С - 100.
> Процент ансейф кода в С - 100.Так это про любой ЯП можно сказать, в том числе про Ржавого.
И да, прежде чем вы продолжите нести чушь, предъявите пожалуйста код написанный лично вами. Чтобы мы имели представление о квалификации "критика".
> Так это про любой ЯП можно сказать, в том числе про Ржавого.Вот это квалификация!
Вы программированию в каком колхозе учились?
> предъявите пожалуйста код написанный лично вами.
Хм, а чего еще потребуете?
> Чтобы мы имели представление о квалификации "критика".
Думаю код вам не поможет, тк ваша квалификация на уровне дна.
>> Так это про любой ЯП можно сказать, в том числе про Ржавого.
> Вот это квалификация!
> Вы программированию в каком колхозе учились?
>> предъявите пожалуйста код написанный лично вами.
> Хм, а чего еще потребуете?
>> Чтобы мы имели представление о квалификации "критика".
> Думаю код вам не поможет, тк ваша квалификация на уровне дна.Ну т.е. вы расписываетесь в своей полной некомпетентности в программировании. А значит ценность вашего мнения по данному вопросу - нулевая. Хорошо, спасибо, больше вопросов не имею.
>И да, прежде чем вы продолжите нести чушь, предъявите пожалуйста код написанный лично вами. Чтобы мы имели представление о квалификации "критика".Для тех кто не в курсе, напоминаю, что ProfessorNavigator ниасилил xml парсер. И даже когда ему указали на конкретные строки и сказали в чём ошибка, он это так и не поправил. Оправдывается тем, что ему не нужен полноценный парсер, ему и суррогат сойдёт.
>>И да, прежде чем вы продолжите нести чушь, предъявите пожалуйста код написанный лично вами. Чтобы мы имели представление о квалификации "критика".
> Для тех кто не в курсе, напоминаю, что ProfessorNavigator ниасилил xml парсер.
> И даже когда ему указали на конкретные строки и сказали в
> чём ошибка, он это так и не поправил. Оправдывается тем, что
> ему не нужен полноценный парсер, ему и суррогат сойдёт.Да завсегдатаи opennet все знают кто это.
>>>И да, прежде чем вы продолжите нести чушь, предъявите пожалуйста код написанный лично вами. Чтобы мы имели представление о квалификации "критика".
>> Для тех кто не в курсе, напоминаю, что ProfessorNavigator ниасилил xml парсер.
>> И даже когда ему указали на конкретные строки и сказали в
>> чём ошибка, он это так и не поправил. Оправдывается тем, что
>> ему не нужен полноценный парсер, ему и суррогат сойдёт.
> Да завсегдатаи opennet все знают кто это.Кстати, было бы интересно узнать независимое мнение. Без шуток.
Если в FB2 используется только ограниченный набор возможностей из xml, то для работы с FB2 и нужен парсер этих возможностей. Дополнительный код - дополнительная поверхность атаки и ненужное усложнение.
> Если в FB2 используется только ограниченный набор возможностей из xml, то для
> работы с FB2 и нужен парсер этих возможностей. Дополнительный код -
> дополнительная поверхность атаки и ненужное усложнение.Вы, я так подозреваю, с адресатом ошиблись ;)
>Если в FB2 используется только ограниченный набор возможностей из xml, то для работы с FB2 и нужен парсер этих возможностей.Есть такое волшебное слово, как спецификация. И несоблюдение спецификации приведёт к тому, что вместо реальных данных будет прочитан какой-то мусор. Кроме того, безотносительно спецификации, я уже не раз писал, что парсер должен работать от начала документа к концу, а реализация от ProfessorNavigator-а наматывает круги по документу. И если в отношении соблюдения спецификации были робкие шаги, то вот избавится от нескольких циклов он так и не осилил.
>Дополнительный код - дополнительная поверхность атаки и ненужное усложнение.Ну так читайте книги в txt формате. Зачем вам fb2?
> Есть такое волшебное слово, как спецификация.Спецификация xml и xml допустимый в FB2 - это разные вещи.
Полная реализация xml в данном случае будет совершенно излишним усложнением приводящая к очень сильному увеличению поверхности атаки. Вон у разработчика libxml2 спросите. Почему он не осилил полную спецификацию xml без CVE.
А в читалке - это важно. Ибо данные могут быть подготовлены для атаки.
> Зачем вам fb2?
Ваше мнение очень важно для нас.
> Для тех кто не в курсе, напоминаю, что ProfessorNavigator ниасилил xml парсер.
> И даже когда ему указали на конкретные строки и сказали в
> чём ошибка, он это так и не поправил. Оправдывается тем, что
> ему не нужен полноценный парсер, ему и суррогат сойдёт.Ссылочку на ваш код, пожалуйста. В противном случае цена вашим словам - 0.
>Ссылочку на ваш код, пожалуйстаИ что вы там собираетесь увидеть? Я вам уже скидывал пример написания LR парсера, и вы многозначительно промолчали.
> И что вы там собираетесь увидеть? Я вам уже скидывал пример написания
> LR парсера, и вы многозначительно промолчали.Т.е. вы расписываетесь в том, что к программированию никакого отношения не имеете. А значит цена вашим словам - 0.
Позовите следующего тролля пожалуйста ;)
>Т.е. вы расписываетесь в том, что к программированию никакого отношения не имеетеДа будет известно всяким проффесорам, что в коммерческом программировании код принадлежит работодателю. А иногда, ещё и NDA подписывается.
> Да будет известно всяким проффесорам, что в коммерческом программировании код принадлежит
> работодателю. А иногда, ещё и NDA подписывается.Тогда с вами вообще не о чем разговаривать ;) Но так и быть, в порядке исключения - на каком языке пишете, в какой компании, какой продукт.
>> Зачем вам ремни если вы только и делаете, что их отстегиваете
> Ложная аналогия. Процент ансейф кода в ядре сильно меньше 5. Процент ансейф
> кода в юзерспейсе сильно меньше 1.
> Процент ансейф кода в С - 100.У хирурга есть очень потенциально опасный инструмент. Называется скальпель. И грамотный хирург умеет им пользоваться очень безопасно.
Дай данному хирургу инструмент аналог РЖИ и он не сможет провести операцию вообще.
Поэтому если дурачки не умеют пользоваться "скальпелем" то и лезти туда не стоит, а тем более в системы типа Ядер операционных систем.
В чем суть хорошей работы грамотного хирурга - 6 лет обучения с огромной практикой.
Большинство Расто-манов зачастую вообще без высшего образования, залетные на "большие бабки в IT-отрасли".
смысл что оплошности компилятор не пропустит на расте. а если уж лезть за забор - так уж точно будет видно что куда и откуда.
У хирурга есть очень потенциально опасный инструмент. Называется скальпель. И грамотный хирург умеет им пользоваться очень безопасно.
Дай данному хирургу инструмент аналог РЖИ и он не сможет провести операцию вообще.
Поэтому если дурачки не умеют пользоваться "скальпелем" то и лезти туда не стоит.
В чем суть хорошей работы грамотного хирурга - 6 лет обучения с огромной практикой.
Большинство Расто-манов зачастую вообще без высшего образования, залетные на "большие бабки в IT-отрасли".
> У хирурга есть очень потенциально опасный инструмент. Называется скальпель. И грамотный хирург умеет им пользоваться очень безопасно.Ага, а еще кольчужные перчатки, антисетпик и еще куча всего.
> Дай данному хирургу инструмент аналог РЖИ и он не сможет провести операцию вообще.
Ты сейчас про дыряшку?
Ну так 150 CVE за месяц нашли)> Поэтому если дурачки не умеют пользоваться "скальпелем" то и лезти туда не стоит.
Тонны CVE в ядре как раз про это говорят)))
>> У хирурга есть очень потенциально опасный инструмент. Называется скальпель. И грамотный хирург умеет им пользоваться очень безопасно.
> Ага, а еще кольчужные перчатки, антисетпик и еще куча всего.
>> Дай данному хирургу инструмент аналог РЖИ и он не сможет провести операцию вообще.
> Ты сейчас про дыряшку?
> Ну так 150 CVE за месяц нашли)
>> Поэтому если дурачки не умеют пользоваться "скальпелем" то и лезти туда не стоит.
> Тонны CVE в ядре как раз про это говорят)))Так вот я о том что проблема не в инструменте совсем, проблема в образовании недопрограммистов.
> Так вот я о том что проблема не в инструменте совсем, проблема в образовании недопрограммистов.В ядре люди, которые пишут код десяти лет.
У вас все кто делают ошибки "недопрограммисты".
Может покажете проект на СИ где таких ошибок нет?
Я пойду спрашивать этих убершеншей как они так смогли.
Ядро проект большой и давний, активно развиваемый разномастной толпой. Ошибки допускают, ошибки исправляют.
А на Расте даже чужие консольные утилиты десять лет портировать не могут, чтобы на равном месте не облажаться.
Та что да, уровень программиста решает. Инструмент - дело десятое.
Я бы сказал - С переписывать на С смысла нет, так же как и "пытаться переписать".
Другое дело С переписать на C++ это значительно уменьшит количество проблем с выделением и освобождением памяти и ошибки выхода за пределы структур/классов.
>Другое дело С переписать на C++У крестовиков совсем совести нет. Они умудряются критиковать раст за долгое время сборки, но сами пишут на крестах.
>это значительно уменьшит количество проблем с выделением и освобождением памятиВ крестах точно так же есть UB, сырые указатели и прочие сишные ошибки.
>и ошибки выхода за пределы структур/классов.Для этого нужны зависимые типы, но крестовики их ниасилили.
>>Другое дело С переписать на C++
> У крестовиков совсем совести нет. Они умудряются критиковать раст за долгое время
> сборки, но сами пишут на крестах.
>>это значительно уменьшит количество проблем с выделением и освобождением памяти
> В крестах точно так же есть UB, сырые указатели и прочие сишные
> ошибки.
>>и ошибки выхода за пределы структур/классов.
> Для этого нужны зависимые типы, но крестовики их ниасилили.че за бред? недопрограммиста видно сразу. Который ни в зуб ногой ни в С ни в С++.
Время компиляции С++ сравнимо с обычным С. Откровенно врать не стоит. Проблема именно в компиляторе - llvm это принципиально другая логика получения рабочего кода для процессора исполнения чем тот-же GCC. Но недопрограммистам это естественно неизвестно/непонятно.
Структуры данных на С - это ад. Классы в С++ - это рай. Особенно по выделению/освобождению памяти под них.независимые типы - работа с template.
>Время компиляции С++ сравнимо с обычным С.Лгать не надо. https://habr.com/ru/companies/jugru/articles/438260/
>Если вы вдруг подумали, что «меньше 3 секунд» — слишком маленькое время, то совершенно нет. За три секунды современный CPU может произвести несметное число операций. Например, за какое время clang сможет скомпилировать настоящий полноценный движок базы данных (SQLite) в отладочном режиме, включая все 220 тысяч строчек кода? За 0.9 секунд на моём ноутбуке. В какой такой вселенной стало нормальным, чтобы тривиальный пример на 5 строчек компилировался в три раза дольше целого движка баз данных?Если бы вы хотя бы раз писали бы на golang или ocaml, то вы бы знали, что такое быстрая компиляция.
>Структуры данных на С - это ад. Классы в С++ - это рай.При чём здесь классы?
>независимые типы - работа с template.Вместо того, чтобы вбить в поисковик "зависимые типи данных", и выяснить, как компилятор может в момент компиляции доказать, например, отсутствия выхода за границы массива, крестовик начинает выдумывать что-то про шаблоны. Почему я не удивлён?
> или ocaml, то вы бы знали, что такое быстрая компиляция.Тут обратил внимание, что прототипы компиляторов для создаваемых языков программирования часто пишут на ocaml.
Возник вопрос почему?
>Возник вопрос почему?Потому, что это очень удобно. Написание компиляторов в целом хорошо ложится на функциональное программирование, а Ocaml даёт кучу возможностей, вроде сборки мусора, вывода типов, статической типизации, быстрой компиляции. При желании можно запросто использовать и ООП подход. Написание аналогичного кода на c++ потребует гораздо больших усилий. Haskell куда сложнее в освоении, плюс из-за ленивых вычислений может весьма сильно потреблять память.
> Написание аналогичного кода на c++ потребует гораздо больших усилий.Почему? И там и там можно писать в любом стиле.
> Haskell куда сложнее в освоении
Для разработчиков компиляторов это вообще не проблема.
> плюс из-за ленивых вычислений может весьма сильно потреблять память
Пишут прототипы. И потом переписывают ибо скорость работы мала и ресурсов требует много. Так что вообще не аргумент.
> Время компиляции С++ сравнимо с обычным С.Если использовать библиотеки из Си. Если использовать включаемые header-only нагромождения C++ шаблонов (templates), вместо разделяемых библиотек, то время компиляции (за счёт автоподстановки/дедукции шаблонов) может вырасти до небес. Правда, всё ещё существенно лучше Rust-а.
> Структуры данных на С - это ад. Классы в С++ - это рай.
Си-структуры простые как палка и предсказуемые. Хотя бы, не подставляют по странным правилам автоматические конструкторы и деструкторы, которых не видно, а они есть (как в "ДМБ").
Суть новости: в байндере на расте целая CVE, но вы видели сколько на Си там ошибок? Аж 159!
суть новости что большинство пограмистов нужно тянуть за ручку
Ого, это за 35 лет? Ну и начерта тогда ваш раст там.
> Ого, это за 35 лет?Ахаха, за 35! Если бы...
Тут lore.kernel.org/linux-cve-announce только за декабрь 2025го целая страница(((
А за год больше 1.5к, и это год еще не закончился.
Сложно сказать.>Service is currently unavailable.
Видимо, никого не интересует эта видимость полезной деятельности.
По ссылке там всё в кучу намешно, ни одной реальной уязвимости так и не накликал.
>Service is currently unavailable.Может без квн не пускает?
Потому что у меня все открывается.> ни одной реальной уязвимости так и не накликал.
Да ладно! Вот из первого же десятка
will result in kernel panic.
lore.kernel.org/linux-cve-announce/2025121651-CVE-2025-68309-1029@gregkh/T/#u
>> lore.kernel.org/linux-cve-announce
> По ссылке там всё в кучу намешно, ни одной реальной уязвимости так и не накликал.Вот это копиум! В списке CVE нет CVE. 😂
Да там ощущение всё подряд пихают, независимо от применимости. Самые реалистичные какие-то забытые проверки, из-за чего улетает в панику, или отладочные сообщения с утечкой кишок. Раст от подобного никак не защитит так-то.
> экспертиза
> копиумТы как радиостанция судного дня.
Так там серьезных CVE со взломом рута реально нет, беспокоиться смысла нет. Кстати, использование смайликов дополнительно показывает, что ты раст-о-вик.
это за месяц. 1 к полутора сотням соотношение найденных, не хило да? ну само собой поправка на то, что раста мало. но тенденция неплоха, согласитесь, если всё начнут перелопачивать
Нет. Суть новости:В коде на Си всего-то 159 ошибок, это несерьезно даже, но посмотрите на Раст - там целая одна, это же позор! Куда попгроммисты глядели!
"Остальные уязвимости решили на Раст мы уязвимостями считать не будем"?
"На раст невозможны существования уязвимостей"
Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен, сели в лужу. Не в первый раз уже причем.
> Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен,Да, он крут и безопасен в рамках гарантий которые он дает.
> сели в лужу.
Только в фанатазиях хейтеров.
А рамки гарантий там, где пока еще ничего не нашли.
Очень удобно.Как там рамки гарантий под mips? Когда будут?
Или "нет кода - нет уязвимостей"?
> Как там рамки гарантий под mips? Когда будут?Tier: 3
Вам нужно - вы и пилите.> Или "нет кода - нет уязвимостей"?
Уязвимость может быть в алгоритме.
Даже кода нет, а уязвимость есть.
> Tier: 3. Вам нужно - вы и пилите.Пилить что? У вас даже языка нет, всё время "эта фича была добавлена/убрана/изменена вчера/завтра". Причём код одной версии не будет компилироваться на другой версии. Даже у ещё не вышедшего Jai проблем таких не было в таком количестве.
>Да, он крут и безопасен в рамках гарантий которые он дает.Ахаха, ты очки надень и "рамки" те рассмотри, вдруг можешь обнаружить, что тех "рамок" дай боже на форточку хватит, а заявка была на "весь мир остеклим"...
Короче, как и озвучивалось, раст - для превращения линуксов в корпоративную ОСь, а "безопасность" - лишь предлог для централизации...
> Да, он крут и безопасен в рамках гарантий которые он дает.Жаль только, что не выходя за "рамки" на Расте вообще писать не получается.
А вообще, так можно про любой язык сказать: "Си крут и безопасен в рамках гарантий, которые он даёт."
Так любой язык безопасен в рамках его гарантий и правильного кодирования.Благодаря проекту sudo-rs у хакеров появилось несколько десятков новых векторов атак на систему, которых не было в классическом sudo.
> Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен, сели в лужуЕсли одна растовая CVE - это "сели в лужу", то куда сели сишочники со своими 159 CVE? 🤔
> Если одна растовая CVE - это "сели в лужу", то куда сели сишочники со своими 159 CVE? 🤔Все верно.
Растовики сели.
А сишники из нее и не подымались))
Это не CVE со взломом рута, а Deny-Of-Service в худшем случае.
> Если одна растовая CVE - это "сели в лужу", то куда сели сишочники со своими 159 CVE? 🤔Никуда. Кода на Си в 1000 раз больше, а функциональности в 10.000 раз (сишка гораздо лаконичнее, так что нет смысла сравнивать по строкам - большая их часть в rust ничего полезного не делает)
>> 159 новых сишочных CVE за месяц
> Никуда не селиАбсолютный копиум.
Поражаюсь, как они передоз не ловят. Десятилетия практики!
Там все эти ошибки не являются настоящими серьезными CVE и ни к чему серьезному привести не могут.
> Проблема вызвана состоянием гонки при выполнении операций в блоках unsafe, напрямую работающих с указателями на предыдущий и следующий элементы списка.Ну т.е. расто-вики ничем не лучше и ни разу не квалифицированнее дидов-сишников при работе с сырыми указателями? А разговоров то было...
тут хотя ансейвом ограждают, широта использования этим не ограничивается же
И что, помогло?
Да, помогло: посмотрели в unsafe блоки и нашли баг. А куда нужно смотреть в сишном коде, м? Правильный ответ: в весь код.
> дидов-сишников при работе с сырыми указателямиТак сейчас на расте пишут в ядро те же самые диды.
Но как раз то, что уязвимость в unsafe коде, а не в обычном - показывает что оно таки работает. Теперь нужно избавляться от unsafe.
А без избавления от unsafe эти расто-manы не могут написать нормально без CVE?> напрямую работающих с указателями на предыдущий и следующий элементы списка.
Т.е. тут что получается - расто-manы запутались в linked list? Серьезно?
> А без избавления от unsafe эти расто-manы не могут написать нормально без CVE?Так в том-то и дело что никто не может))
Поэтому задача для начала - разделить код на safe и unsafe.
А потом улучшать проверки компилятора, чтобы он мог больше кода доказывать.> расто-manы запутались в linked list?
Да, в локах листа.
> А без избавления от unsafe эти расто-manы не могут написать нормально без CVE?Сишочники тоже не могут, так что твои претензии непонятны.
> Сишочники тоже не могут, так что твои претензии непонятны.Не "сишочники", а: "В Google не умеют писать на С, поэтому пытаются пропихнуть в ядро непонятно что. На чём тоже не умеют писать".
В общим - исправил, можно не благодарить.
Старое-доброе "чтобы не было ошибок - не делайте ошибки".> В Google не умеют писать на С,
А где могут, и что из-под их пера вышло?
> Старое-доброе "чтобы не было ошибок - не делайте ошибки".Не нужно перевирать. Ещё раз: "В Google не умеют писать на С, поэтому пытаются пропихнуть в ядро непонятно что. На чём тоже не умеют писать".
> А где могут, и что из-под их пера вышло?
А при чём здесь другие, если ошибку допустили программисты Google?
> А при чём здесь другие, если ошибку допустили программисты Google?Ну раз у них не получается, то ты покажите тех, у кого ошибок нет.
Мы на них посмотрим и пойдем у них учиться.
Логично же?!
> Ну раз у них не получается, то ты покажите тех, у кого
> ошибок нет.
> Мы на них посмотрим и пойдем у них учиться.
> Логично же?!Т.е. вы утверждаете, что весь код на Rust - с ошибками? И зачем он тогда нужен?
> Т.е. вы утверждаете, что весь код на Rust - с ошибками?Хм, профессор, это у вас уже что, деменция?
Вы говорите что в гугле не умеют писать. На СИ.
Ваша же цитата "В Google не умеют писать на С" ?Ну так я хочу научиться классно писать на СИ.
И мне нужны крутые СИшники которые не делают ошибок.И тут два варианта:
- вы скрываете существование такого проекта (что довольно эгоистично)
- на СИ невозможно писать без ошибок
>> Т.е. вы утверждаете, что весь код на Rust - с ошибками?
> Хм, профессор, это у вас уже что, деменция?
> Вы говорите что в гугле не умеют писать. На СИ.
> Ваша же цитата "В Google не умеют писать на С" ?
> Ну так я хочу научиться классно писать на СИ.
> И мне нужны крутые СИшники которые не делают ошибок.
> И тут два варианта:
> - вы скрываете существование такого проекта (что довольно эгоистично)
> - на СИ невозможно писать без ошибокНе нужно лгать. Цитата:
"В Google не умеют писать на С, поэтому пытаются пропихнуть в ядро непонятно что. На чём тоже не умеют писать".При этом ошибку мы обсуждаем в коде на Rust - про это собственно новость.
И да - ссылку на лично вами написанный код пожалуйста, потом продолжим.
>> Ваша же цитата "В Google не умеют писать на С"
> Не нужно лгать.Уровень извивания на сковороде просто фантастический. 🤣
> Уровень извивания на сковороде просто фантастический. 🤣Самокритично))
>> А где могут, и что из-под их пера вышло?
> А при чём здесь другие, если ошибку допустили программисты Google?При том, что ты сказал "в Google не умеют писать на С". Если в Google не умеют, то я спрашиваю - где умеют? Это простой вопрос. Ты в состоянии на него ответить?
>>> А где могут, и что из-под их пера вышло?
>> А при чём здесь другие, если ошибку допустили программисты Google?
> При том, что ты сказал "в Google не умеют писать на С".
> Если в Google не умеют, то я спрашиваю - где умеют?
> Это простой вопрос. Ты в состоянии на него ответить?https://www.opennet.me/openforum/vsluhforumID3/138667.html#171
Прибавить мне по-прежнему нечего.
>> Ты в состоянии на него ответить?
> Прибавить мне по-прежнему нечего.Ну ок. Зачем ты только тут всплывал - непонятно...
Именно, дружище, именно...> Ну ок. Зачем ты только тут всплывал - непонятно...
Вопрос по предъявлению кода к вам, кстати, тоже относится.
Было бы интересно заценить цифру отношения количества unsafe-специфичных ошибок к количеству строк кода в С (весь код) и в Rust (unsafe блоки). Хотя вряд ли это собьет спесь с растоманов.
растаманы не отвечают за ансейф. сишники не отвечают ни за что. лол.
> растаманы не отвечают за ансейф. сишники не отвечают ни за что. лол.Прежде, чем утверждать такое, покажите пожалуйста код, написанный лично вами. Чтобы мы знали уровень вашей экспертизы.
Если посмотреть код, то добавили локи.
Интересно есть (были ли) тесты для такого варианта?- let death_list = core::mem::take(&mut self.inner.access_mut(&mut guard).death_list);
- drop(guard);
- for death in death_list {
+ while let Some(death) = self.inner.access_mut(&mut guard).death_list.pop_front() {
+ drop(guard);
death.into_arc().set_dead();
+ guard = self.owner.inner.lock();
> Примечательно, что помимо уязвимости в Binder вчера были опубликованы сведения о 159 уязвимостях в различных компонентах ядра Linux, написанных на языке Си.Но новость написали про Раст 😇
Заботятся о посещаемости форума, чтобы комменты не застаивались.
Бурление помогает людям общаться и скидывать негативные эмоции на анонимов, которых не жалко.ps
Какое именно правило форума нарушили мои предыдущие сообщения?
Нет ли тут можераторского произвола?
>вчера были опубликованы сведения о 159 уязвимостях в различных компонентах ядра Linux, написанных на языке Си.Это предложение пахнет желтизной. Си - это рабочая лошадка. Закрытие уязвимостей обычнная работа, не надо тут раздувать из мухи слона.
Для системного программирования нет ничего лучше чистого Си.
> Си - это рабочая лошадка.Старая и дряхлая.
> Закрытие уязвимостей обычнная работа, не надо тут раздувать из мухи слона.
А написание уязвимостей? Тоже обычная работа?
Тут целая новость из-за ОДНОЙ ошибки в расте, а 150 в СИ мало кого волнуют.> Для системного программирования нет ничего лучше чистого Си.
По мнению кого?
Вон разработчики ядра решили что это не так.
У вас есть более высокии компетенции?
вот и миллионы индусов так говорят, пуляя новые ежемесячные апдейты на винду
> Закрытие уязвимостей обычнная работаКак, собственно, и их создание...
> в различных компонентах ядраКлючевое слово: "в различных". А в сабже - один компонент биндер. Тогда пусть бы приводили таблицу по компонентам.
> напрямую работающих с указателями на предыдущий и следующий элементы спискаЭлементарный список не осилили. Какая же жесть должна быть в структурах посложнее.
так все опытные пограмисты новый язык уже где-то с середины книжки изучать начинают, пропуская вводую воду
Это язык в котором элементарный список без unsafe не делается.
> Это язык в котором элементарный список без unsafe не делается.Пф, а на СИ или плюсах это список будет safe? Или нет?
Дырявые ЯП unsafe полностью, от первой строчки до последней.
Найди реализованный в ядре список с проблемами у указателями.Их там тысячи, если что. И намного сложнее. Просто вся логика для восприятия проще.
> Найди реализованный в ядре список с проблемами у указателями.Абсолютно любой, который не thread-safe. Ты же в новости читал, что проблема в состоянии гонки, а не в самой логике работы списка?
падажжи, так а зачем они закодили состояние гонки на безопасном расте?
> состояние гонкичтобы было блэзинг фаст
Тут проблема в том, что они делали потокобезопасный список. И облажались.
А они думали в сказку попали чтоли? Конечно в ядре он должен быть thread-safe.
Важен сам факт доступа к ресурсу и/или его лайвтайм. Если таки открыть изначальное сообщение об уязвимости, улыбаемся и машем - растовичане забыли, что лист создавался для того, чтобы его читали другие компоненты системы. Листы там инлайновые, т.е. каждая нода листа и есть объект. Самое забавное, что проблему создаёт "safe" код из Node::release, потому что он копипастит лист и отпускает лок, а потом начинает итерировать то, что убирает "unsafe" код, справедливо пологая, что этот элемент (и данные, лежащие в нём) уникальны и нигде больше не референсятся. Упс, боров чекер обманул сам себя, получается?
Это язык в котором чтение из union - по определению unsafe. :)
А вы про список.
Хахаха, а ведь смешно облажались 😂
Радует только что в ансефе, а то совсем неудобно бы было.Впрочем, за свои действия нужно отвечать.
Готов принять лучи ненависти как топящий за раст.
> Хахаха, а ведь смешно облажалисьТы вот про этих? Настолько смешно, что уже даже не расписывают в новости, что опять накосолапили Сишники.
> вчера были опубликованы сведения о 159 уязвимостях в различных компонентах ядра Linux, написанных на языке Си
> Ты вот про этих? Настолько смешно, что уже даже не расписывают в
> новости, что опять накосолапили Сишники.Да ладно тебе.
Ну есть ошибка в unsafe, пусть порадуются, тебе что жалко?
Вот выйдет новость про какую-то сишную дырень, там уже мы поухмыляемся.
> вчера были опубликованы сведения о 159 уязвимостях в различных компонентах ядра Linux,
> написанных на языке СиТак просто для Си это норма.
Эта уязвимость приводит к крешу. В списке 159 как минимум несколько тоже приводят к крешу ядра... но всем пофиг, потому что "не, ну это сишка же".Поэтому у кого-то сегодня будет праздник. Ну ничего, мы это переживем)
>Радует только что в ансефе, а то совсем неудобно бы было.На гитхабе видел проект, где безопасным по мнению растокомпилятора кодом нарушается целостность памяти.
Не могу вспомнить, как он назывался.
> На гитхабе видел проект, где безопасным по мнению растокомпилятора кодом нарушается целостность памяти.
> Не могу вспомнить, как он назывался.Подскажу, cve-rs
Там использовалась кастомная реисплементация mem::transmute и std::ptr::null()
Уже исправлено в miri
> ...о 159 уязвимостях...Это победа, господа!
вайб кодеры с гуманитарным образованием еще и не такое накодят, все самое смешное впереди
Вот только это были Си-деды. Неудобно как-то получилось.
Си-деды накодили бэкдоров, а не просто так ошибок в памяти понаделали. Как раз чтобы школята, которым впадлу даже сурсы читать и у которых мозг ломается от возможности того, что не весь код должен быть защищён от того, что в компьютер прилетит метеор, не заметили. Понимать разницу надо.
Если прилетит, то это уже метеорит, а не метеор
Там максимум Deny-Of-Service, взлома рута нет, беспокоиться тоже смысла нет.
Падение ядра... Это трында всей системе. С потерей данных.
> Binder, написанном на языке Rust, устранена уязвимость (CVE-2025-68260).Но как же так, Холмс? :))
> При успешной эксплуатации уязвимость в Binder ограничивается аварийным завершением и не приводит к повреждению памяти.
Спасибо за разъяснения, безопасТная уяхвимость получилась! Так, стоп, а CVE тогда зачем? :)
> а CVE тогда зачем?Пользователь очень радуется, когда ядро падает. Вместе с потерей всех данных.
> Пользователь очень радуется, когда ядро падает. Вместе с потерей всех данных.А еще больше он радуется, когда узнает что у него было RCE и 10 лет у него на серваке был проходной двор.
Особенно если за это его будут штрафовать по всяким ФЗ или GDPR
> Так, стоп, а CVE тогда зачем? :)Потому что Rust в ядре больше не эксперимент.
Если ядро аварийно завершает работу, то какая разница в порядке ли память ...
То есть, ошибка в той части ядра, на которую тут регулярно ссылаются при попытках доказать безопасность Rust? Google тоже дилетанты как и Cloudflare получается?
> То есть, ошибка в той части ядра, на которую тут регулярно ссылаются при попытках доказать безопасность Rust?Ээээ? Андроид еще использует страый биндер.
Ты чего-то попутал.> Google тоже дилетанты как и Cloudflare получается?
Так все ошибаются! Именно поэтому нужно вводить автоматические проверки.
Эта ошибка как раз показывает "нужно улучшать инструменты".
>Эта ошибка как раз показывает "нужно улучшать инструменты".Вот с этим соглашусь. При должном развитии статических анализаторов надобность в Rust отпадёт сама собой. Радует, что в этом направлении есть подвижки.
> Вот с этим соглашусь. При должном развитии статических анализаторов надобность в Rust отпадёт сама собой.А зачем было ждать 10-20 лет, пока не начали раст изобретать?))
> Радует, что в этом направлении есть подвижки.
Медленные, это к сожалению, раз.
А два - пока подвижки недостаточные. Ни один из стат анализаторов не дает такие проверки владения.
> А зачем было ждать 10-20 лет, пока не начали раст изобретать?))Не совсем так. Пока лобби не начало пропихивать требования госконторы.
До этого проблема не воспринималась, серьезной. Для этого, идеологически, лучше подходит изменение архитектуры железа, чем компилятора.
Требования пропихнули.
Ну, надо крутиться.
> Не совсем так. Пока лобби не начало пропихивать требования госконторы.Причем тут госконторы?
Или программистам ядра было норм что у них куча ошибок, а в некоторых случаях еще и RCE, повышение привилегий и тд?
Постоянное игнорирование последнего, так вообще попахивает саботажем или бекдорами.> До этого проблема не воспринималась, серьезной.
Ну, т.е пока ГОС не стукнет, программеру было побоку?
> Для этого, идеологически, лучше подходит изменение архитектуры железа, чем компилятора.
Не правда.
Они только добавляли уязвимости основанные на спекулятивном исполнении, всякие спектры и мелтдауны.
ChkTag начали стандартизировать буквально сейчас.Т.е просто всем было пофиг.
> Не правда.Что неправда. Что защита в железе - это гарантия.
> Они только добавляли уязвимости основанные на спекулятивном исполнении, всякие спектры и мелтдауны.
Это невидимая рука рынка. На безопасность большинству положить. Потому такие процессоры и делают и будут делать.
> ChkTag начали стандартизировать буквально сейчас.
А вот это да. Жареный петух клюнул. Теперь надо что-то делать. Дольше чем компиляторы, но сделают.
> Что неправда. Что защита в железе - это гарантия.Да, если она сделана качественно.
CPU AMD Zen 5 подвержены уязвимости, допускающей изменение микрокода и обход изоляции SEV-SNP
opennet.ru/opennews/art.shtml?num=63055VMScape - атака на CPU AMD и Intel, обходящая изоляцию между гипервизором и гостевой системой
opennet.ru/opennews/art.shtml?num=63868>> всякие спектры и мелтдауны.
> Это невидимая рука рынка. На безопасность большинству положить. Потому такие процессоры и делают и будут делать.Думаю так было.
А потом оказалось, что у юзера на компе у него не только нюдсы, но и работа, банковское приложение, криптокошельки и тд> А вот это да. Жареный петух клюнул. Теперь надо что-то делать. Дольше чем компиляторы, но сделают.
Т.е это будет еще лет 5, а то и больше.
И работать оно будет только в новых процессорах.
Что делать со старыми? Выкинуть?
Или попытаться улучшить код, чтобы дырок было меньше.
> Да, если она сделана качественно.Ага. А есть еще память. Которая ничего не гарантирует.
Однако всеми продается и покупается.
А что бы с гарантией - надо отдельно заморачиваться за совсем другую цену.
Вся IT, построенная на рыночных основах - полный трешь и угар.
>При должном развитии статических анализаторов надобность в Rust отпадёт сама собой. Радует, что в этом направлении есть подвижки.Ага. Уже более чем полвека прошло, а нет ни-че-го. Вот ноль, полный ноль.
Что-то мне кажется, что этот Диды СИшники специально так сделали, чтобы дискредитировать Rust. Там достаточно недовольных, так что такие диверсии могут теперь быть частыми
Сомнительно.
Биндер писали сотрудники гугла (aliceryhl@google.com)
За диверсию можно и партбилет положить на стол.
Такое только программисты на Rust могут сделать. В C ошибки скучные, а тут не смогли написать связный список!
>Такое только программисты на Rust могут сделать. В C ошибки скучные, а тут не смогли написать связный список!Так им всё равно надо Звезду Героя дать. На таком брейнфаке написать хоть что-то похожее на работающее.
> В C ошибки скучные"Не смогли посчитать размер строки" или "не смогли написать split строки" это скучная или нет?
> а тут не смогли написать связный список
Список они написали, а с локами запутались.
Даже приятно что первая уязвимость оказалась такая, а не унылая off-by-one error))
>Что-то мне кажется, что этот Диды СИшники специально так сделали, чтобы дискредитировать RustНе, сами, сами справляются
Да-да, конечно)) Во всём "деды-сишники" виноваты, а не Google, программисты которого даже на Rust не могут нормально писать. При этом Google же и ваш дружный хор его платных подпевал всё равно продолжают везде упорно рассказывать, что дело в языке программирования, да. А не в том, что кто-то нанимает людей с низкой квалификацией, сам никого не обучает и условия труда при этом как на галере.Нету, ребята, нету серебряной пули. И прибыли вам ничто не подымет - всё, планета кончилась. Да и вы скоро закончитесь, поэтому собственно так ожесточённо везде и лезете.
> Во всём "деды-сишники" виноваты, а не Google, программисты которого даже на Rust не могут нормально писать.Почему не могут? Могут.
Всего одна ошибка. Сравните это с 150 от дидов.> что дело в языке программирования, да.
Да, если вам врач предложит вырывать зуб пассатижами, а не специальным инстирументом, вы согласитесь?
> нанимает людей с низкой квалификацией,
А чего тогда есть ошибки в проектах, без корпораций?
Там никого не нанимают, а ошибки есть.> Нету, ребята, нету серебряной пули.
Конечно нету. Выше кидали цитату Грега Хартмана где он именно это и говорит.
Но "не серебьрянная пуля" и "лучше недоязыка из 70х" это разные вещи)> Да и вы скоро закончитесь,
Только после вас)
У меня будет отличная мотивация сплясать в комментах на вашей могилке.
Но делать этого я не буду, ну чтобы не уподобляться вам.
>[оверквотинг удален]
> А чего тогда есть ошибки в проектах, без корпораций?
> Там никого не нанимают, а ошибки есть.
>> Нету, ребята, нету серебряной пули.
> Конечно нету. Выше кидали цитату Грега Хартмана где он именно это и
> говорит.
> Но "не серебьрянная пуля" и "лучше недоязыка из 70х" это разные вещи)
>> Да и вы скоро закончитесь,
> Только после вас)
> У меня будет отличная мотивация сплясать в комментах на вашей могилке.
> Но делать этого я не буду, ну чтобы не уподобляться вам.Ссылочку на код, написанный лично вами, пожалуйста давайте. И только после этого продолжим.
> Всего одна ошибка. Сравните это с 150 от дидов.Одна на 1000 строк кода в сравнении с 150 на пару миллионов - да нормально.
> А не в том, что кто-то нанимает людей с низкой квалификацией,
> сам никого не обучает и условия труда при этом как на галере.
> условия труда при этом как на галере.Что??? Это у гугла условия труда как на галере?!
Вы посмотрите какие у них условия труда и зарплаты!
Не пишите бред про то, что не знаете.Ну и про квалификацию вы тоже не правы. Если так рассуждать - то в ядре вообще нет квалифицированных разработчиков.
> Что??? Это у гугла условия труда как на галере?!
> Вы посмотрите какие у них условия труда и зарплаты!
> Не пишите бред про то, что не знаете.А что ж они тогда уязвимости втыкают?))
> Ну и про квалификацию вы тоже не правы.
Вопрос тот же.
> А что ж они тогда уязвимости втыкают?))Просто потому уязвимости не связаны с условиями работы.
А все ограничено физическими лимитами человека на внимательность.
Что в теории можно чуть-чуть подтянуть тренировками, но все равно найдется кодовая база с размером где любой человек не уследит.Просто джун запутается в 10 строчках, мидл в 100, а дед в 1000.
Но это гарантирова рано или поздно произойдет.
И мы собственно это наблюдаем с ростом размера кодовой базы ядра - связи становятся все запутаннее и неочевиднее.
> Просто потому уязвимости не связаны с условиями работы.
> А все ограничено физическими лимитами человека на внимательность.
> Что в теории можно чуть-чуть подтянуть тренировками, но все равно найдется кодовая
> база с размером где любой человек не уследит.Нанимайте/обучайте больше людей.
> Просто джун запутается в 10 строчках, мидл в 100, а дед в
> 1000.
> Но это гарантирова рано или поздно произойдет.
> И мы собственно это наблюдаем с ростом размера кодовой базы ядра -
> связи становятся все запутаннее и неочевиднее.Спасибо, кэп ;)
> Нанимайте/обучайте больше людей.Еще раз: это вам не поможет.
Вы можете хоть 100500 людей нанять, но сложность кодовой базы будет выше чем возможности каждого из них. Вы мне сейчас напоминаете менеджера, который думает что если взять 9 женщин, то за месяц появится новый ребенок.И обучение тоже не поможет.
Чему вы будете их обучать? Не выходить за границы массива? Правильно расставлять локи?
Так это знает даже первокурсник, а толку.
> Еще раз: это вам не поможет.
> Вы можете хоть 100500 людей нанять, но сложность кодовой базы будет выше
> чем возможности каждого из них. Вы мне сейчас напоминаете менеджера, который
> думает что если взять 9 женщин, то за месяц появится новый
> ребенок.Ну т.е. про инкапсуляцию вы не в курсе. Разделение труда тоже мимо вас прошло. В общем - не несите чушь.
> И обучение тоже не поможет.
> Чему вы будете их обучать? Не выходить за границы массива? Правильно расставлять
> локи?
> Так это знает даже первокурсник, а толку.Так, товарищ Умник, ссылку на код, написанный лично вами - в студию. И только после этого продолжим обсуждать хоть что-то, касающееся программирования.
>Ну т.е. про инкапсуляцию вы не в курсе.Вы уже написали парсер xml с инкапсуляцией, только вот работать от этого он не начал.
>>Ну т.е. про инкапсуляцию вы не в курсе.
> Вы уже написали парсер xml с инкапсуляцией, только вот работать от этого
> он не начал.Ссылку на ваш код, только после этого продолжим.
>Просто джун запутается в 10 строчках, мидл в 100, а дед в 1000.Доказательства в студию. Что джун, что сеньёр с лёгкостью запутается даже в 1 строчке кода. Инварианты должен проверять компилятор, всегда. И единственное различие в том, может ли джун выразить утверждение с помощью инвариантов или нет.
>Что в теории можно чуть-чуть подтянуть тренировками, но все равно найдется кодовая база с размером где любой человек не уследит.Ага, строчек на пятьдесят, например.
Молодцы Диды значит.
Стоит ли напомнить, что Binder - это из Андроида и для Андроида, т.е. принесли это гугловцы
>Rust не является панацеей, позволяющей избавиться от всех проблем безопасности, но данный язык действительно помогает защититься от определённого класса уязвимостей.а чтобы защититься от других классов уязвимостей, мы будем писать ядро на других языках! По одному на класс.
> а чтобы защититься от других классов уязвимостей, мы будем писать ядро на
> других языках! По одному на класс.Вот когда сможем защититься, тогда и поговорим.
Провести формальную верификация ядра невозможно.
Так что выбор не большой.Но если изобретут Раст-2.0, который закроет еще какой-то пласт дыреней - то то я только за выкинуть устаревший Раст)))
>Но если изобретут Раст-2.0, который закроет еще какой-то пласт дыреней - то то я только за выкинуть устаревший Раст)))Ну так изобретайте раст 2.0. Потом будете ходить и тролить растовиков, не?
> Ну так изобретайте раст 2.0. Потом будете ходить и тролить растовиков, не?Зачем. Достаточно что Project Vorona и Vale показывают концептуальную ущербность языка rust.
До тех пор, пока язык не стабилизируется, не получит набор библиотек, не станет известным, его считай что не существет. Так что идите и изобетайте эти языки.
> До тех пор, пока язык не стабилизируется, не получит набор библиотек, не станет известным, его считай что не существет. Так что идите и изобетайте эти языки.Для формализации концепции реализация не нужна.
Эти проекты во всю мощь освещают что концепция rust недоделанная. Это язык с реализацией ущербной концепции.
примерная иллюстрация ситуации: https://i.ibb.co/FkvFWv95/image.png
какой к чертям binder? есть posix ipc
Гугловцы пилят себе для андроида. Вернее переписывают то что используют сейчас
ну а на кой этот ансейф? чтобы на него все и сваливать, мол падает и приводит к уязвимостям это не код на расте, а ансейф, на то и ансейф, епта а нах тогда раст нужен? если и так все всегда валили на Си? Не криворукий смузихлеб виноват, а ансейф.пс: хорошая причина оправдывания бекдоров, пихайте в ансейф и валите все на ансейф.
> 159 уязвимостях в различных компонентах ядра Linux, написанных на языке Си.Ну так учитывая какой процент кода написан на Си то даже 1:159 по ошибкам будет не в пользу ржавого.
> Ну так учитывая какой процент кода написан на Си то даже 1:159 по ошибкам будет не в пользу ржавого.159 это за месяц.
Сколько там кода в ядро добавилось за этот период?
Для начала скажи, сколько компонентов в ядре?
С каждым днём - всё меньше и меньше. Из полезных, то есть - драйвера там всякие, ещё какая-то чушь. Большинство из них так переписали и почистили рабы на галерах, что вроде бы даже и компилируется, а на мониторе вместо картинки "упси вупси ёр процессор дид факи ваки и больше не запускается" или современное искусство в стиле "чё было в памяти то и нарисую", потому что ВНЕЗАПНО забыли как разговаривать с вон тем чипом вон той железки, которая сидела и никого не трогала.
поделкой из новости ещё никто не пользовался, а там уже гора UBдумай
159 - да гора, никто не спорит, но вот насчёт того, что линксом ещё никто не пользовался - ты загнул.
> в блоках unsafe, напрямую работающих с указателями на предыдущий и следующий элементы спискаРаст до сих пор не умеет даже в двухсвязный список?! 20 лет пилят, а такого базового примитива невозможно без unsafe сделать...
просто скачай из централизованного магазина сниппетов проект "двухсвязный_список_вася_курсач Новая Папка (1)"
> а такого базового примитива невозможно без unsafe сделать...проблема останова, если ваш список зациклится, а это влечет неразрешимость.
Но позвольте, все эксперты в один голос кричали что unsafe это просто работа с указателями сишными, там точно ничего плохого не может быть, все остальное покрыто Rust кодом! И то, что когда указываешь, что у вас тут в коде unsafe, эти эксперты говорят, что мы совершенно не понимаем!
> Но позвольте, все экспертыА эти "все эксперты" сейчас с вами в одной комнате?
> в один голос кричали что unsafe это просто работа с указателями сишными, там точно ничего плохого не может быть,
Может быть, а может не быть.
Если обратиться к документации [1], то unsafe называют superpowers, то что в обычном расткоде делать нельзя, а именно:
1. Dereference a raw pointer.
2. Call an unsafe function or method.
3. Access or modify a mutable static variable.
4. Implement an unsafe trait.
5. Access fields of unions.
Там же можно прочитать предупреждение:
Be warned, however, that you use unsafe Rust at your own risk: If you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing.Но кто ж читает документацию!
> все остальное покрыто Rust кодом!
Да. В остальном раст-коде проверки компилятора работают на максимуме своих возможностей.
> И то, что когда указываешь, что у вас тут в коде unsafe,
То это нормально. Т.к некоторые действия, например биндинги с СИ кодом, невозможно сделать safe.
> эти эксперты говорят, что мы совершенно не понимаем!
Да, вы совершенно не понимаете.
Такое бывает.
Если вам действительно интересна эта тема, то я оставил ссылку на документацию [1] и полезную статью [2][1] doc.rust-lang.org/book/ch20-01-unsafe-rust.html
[2] doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
Дак ведь основная претензия местных писателей хеллоуворлдов на расте в том, что диды не могут strip строки сделать чтоб не выйти за границу буфера.Ну вот этот пример аж и самого гугла, которые постоянно публикуют статистику сколько там кода на расте у них и как там всё безопасно стало, показал что растеры ничем не лучше тех же дидов, когда речь заходит о сырых указателях. Такие же, как вы говорите, инвалиды плодящие CVE.
> 1. Dereference a raw pointer.
> 2. Читай пункт четвёртый
> 3. Access or modify a mutable static variable. (АААА ГЛАБАЛЬНЫЕ ПЕРЕМЕННЫЕ ГРЯДУТ И ЗЯМЛЯ НАЛЯТИТ НА ОСЬ, ШО ЖЕ ДЕЛАТЬ)
> 4. Читай пункт пятый
> 5. Читай пункт первыйКороче язык, в котором запретили работать с памятью. Прям вообще. Классный план, надёжный, если я всё правильно понял. А оптимизировать за меня структуры эта злая училка умеет? Или "и так сойдёт, подумаешь лишний хлам память занимает, в коде ядра то"? И если умеет, ABI кто соблюдать будет?
>И если умеет, ABI кто соблюдать будет?Stable API is nonsense - главный сишник ядра.
> главный сишник ядраА сишник ли он? Если он пел за раст.
О времена, о нравы. Человек, написавший ОС на си выписан из сишников.
> Stable API is nonsenseПожилой фин оказался не совсем прав, увы. Был бы стейбл апи, может не переписывали бы драйвера для всего подряд. Но приходилось бы держать огромную помойку сисколов с механизмами, которые должны быть в юзерспейсе. Понять его можно.
> эти эксперты... запутались в двусвязном списке. То ли ещё будет с более сложными структурами.
Давайте ядро на PowerShell перепишем - будет веселее. А не педеrust этот ваш
Я думал, и говори все это начнется значительно позже, когда на рже будет значительно больше кода. Но нет, облажаться они смогли уже на старте.
Ошибок такого класса на рже будет значительно больше чем на C. И они гораздо более сложно исправимые. Будут фиксить логику под текущий продукт - текущий будет работать, другие продукты будут проблемы собирать лопатами..
Вот интересные сишечники люди - вместо того, чтобы в своём поганом си порядок навести, и спустя более чем полвека наконец-то побороть хотя-бы самые примитивные ошибки, вроде UB при разыменновывании нулевого указателя, сишечники катят бочку на раст. Ну вот не хотят они писать без багов, а тут такое хорошее оправдание подоспело - на расте оказывается тоже есть баги, следовательно в си не баги, а фичи.
Сишники пишут понимая, что все звиздюли полетят к ним и поэтому, в массе своей, понимают что пишут. Растовчане же это секта, которая верит в мощный компилятор и поэтому, в массе своей, вообще не понимают что они пишут и как это работает.
Ну дак и язык создавался для тех, кто не умеет программировать и для всяких веб-сеньоров.
Пользуясь случаем, задам сишникам вопросы: зачем вам нужны негигенические макросы, невозможность статическим анализом в общем случае проверить отсутствие разыменновывания нулевого указателя, strcpy, отсутствие строк даже в 2025 году. Давайте апологеты си, объясняйте.
> Давайте апологеты си, объясняйте.Почему апологеты Си должны объяснять проблемы раста?!
Где вы здесь увидели раст? У вас галлюцинации? Речь про чистейший си, сишнее не бывает.
> Уязвимость в Binder, подсистеме ядра Linux, написанной на Rustнаписанной на Rust
Где вы в моём сообщении увидели намёк на раст?
> зачем вам нужны негигенические макросыЯ хз о чем ты, но макросы это классная штука, которая позволяет собирать бинарник хоть для х86, хоть для ардуины из одного исходника.
> невозможность статическим анализом в общем случае проверить отсутствие разыменновывания нулевого указателя
Госпаде, да сделай ты себе mymalloc функцию которая будет проверять и хоть упроверяйся.
> strcpy, отсутствие строк даже в 2025 году
А зачем? ну всмысле есть куча библиотек которые добавляют возможности всякие разные, но по большей части это нафиг не надо.
>Я хз о чем тыАпологетика уровня сишника
>Госпаде, да сделай ты себе mymallocСишник как всегда не в курсе, что разыменновывание нулевого указателя происходит не в malloc функции. Никогда такого не было и вот опять.
>А зачем?Вот действительно, зачем в 2025 году портить память? Сишники и сами не знают.
Откуда берутся нулевые указатели, о которых ТЫ не знаешь?
Внезапно, но весь код не пишится в одиночку, иногда люди работают в командах и используют библиотеки.
Сишники в курсе, что указатели бывают разные, и даже нулевой указатель может адресовать данные. В других ОС, например, или других архитектурах.Просто сейчас не инициализированный указатель принято ставить 0, при невыделении аллокатор возвращает именно 0 как наиболее универсальный. А могли бы 0x(FF) или ещё извращение типа MAX_SYS_MEM+1.
Ну как то так.
>Сишники в курсе, что указатели бывают разные, и даже нулевой указатель может адресовать данные. В других ОС, например, или других архитектурах.Только вот не надо сказки рассказывать. Проблема не в том, что я не могу разыменновать нулевой указатель, проблема в том, что это - UB.
>>Сишники в курсе, что указатели бывают разные, и даже нулевой указатель может адресовать данные. В других ОС, например, или других архитектурах.
> Только вот не надо сказки рассказывать. Проблема не в том, что я
> не могу разыменновать нулевой указатель, проблема в том, что это -
> UB.А чем оно должно быть?))
Либо определённым поведением, вроде паники, или всё таки разыменновывания этого самого указателя, либо ошибкой компиляции. И касаться это должно абсолютно всего UB.
> Либо определённым поведением, вроде паники, или всё таки разыменновывания этого самого
> указателя, либо ошибкой компиляции. И касаться это должно абсолютно всего UB.Ещё один "адепт" UB... И как вы себе это представляете? Указатель - это просто переменная, содержащая в себе номер байта в памяти. Тип указателя - количество байт, которые нужно прочитать и как их интерпретировать. Само поведения нулевого указателя при этом ещё и от других факторов может зависеть. Потому что где-то нулевой указатель - указывает на реально существующую память, а где-то - нет. Зависит от ОС например. Поэтому в частности в С рекомендуется использовать макрос NULL, насколько мне известно, а в С++ - оператор nullptr. И если вы разыменуете такой указатель, то получите SEGFAULT.
В общем, прежде чем продолжим - ссылочку на код, написанный лично вами, давайте. Чтобы мы представляли уровень вашей "экспертизы".
>И как вы себе это представляете?Меня удивляет, что каждый раз сишные апологеты с лёгкостью игнорируют уже приведённые ранее аргументы. Емнип я уже лично вам скидывал статью https://habr.com/ru/articles/827752/. И вот эту статью https://habr.com/ru/companies/pvs-studio/articles/250701/ я вам тоже уже скидывал. Но вы опять притворяетесь, что ничего не знаете.
>Само поведения нулевого указателя при этом ещё и от других факторов может зависеть.Например, от оптимизирующего компилятора, который решил переписать код за программиста.
>а в С++ - оператор nullptrЭм, с каких пор литерал превартился в оператор?
>И если вы разыменуете такой указатель, то получите SEGFAULT.Не гарантированно.
>В общем, прежде чем продолжим - ссылочку на код, написанный лично вами, давайте.Что вы там хотите увидеть? Вы не мой работодатель, зачем мне показывать мой код вам? Мои pet проекты? Вот возьмём тему парсеров, я думаю, что даже если вам скинуть shift/reduce конфликт, то вы грамматику не поправите.
>Чтобы мы представляли уровень вашей "экспертизы".Чтобы вы представляли уровень моей экспертизы - я бесплатно вам отревьювил код, и вы потом ошибки исправиляли. Я его даже не запускал. Вы же данные ошибки допустили, и, я так полагаю, если бы не я, то до сих пор бы их так и не поправили.
Ну т.е. вы расписываетесь в том, что ваша квалификация, как программиста - нулевая. Соответственно ценность вашего мнения - такая же.
А вы скажите, как это вы, уважаемый крестовик, смогли написать код так плохо, что я, с ваших слов с нулевой квалификацией, указал вам на ошибки в реализации, просто почитав код? И да, мы обсуждаем не мою квалификацию, а то, что UB не нужен.
Оно вполне определённое, это разыменоввывание нулевого указателя. И результатом может быть:Паника - это в тех runtime, где есть MMU, есть malloc и он может отказаться выделить память. А проверки на NULL/nullptr в коде автора нет. Поэтому здесь разыменовать "нулевой указатель" - получить page fault или аналог.
или
Получение доступа к физической/виртуальной памяти с адресом "мы думаем что 0" - в других системах, с другим вариантом управления памятью.
UB здесь в консерватории^W определении, что это UB так как стандарт языка не может устанавливать ограничения на архитектуру. И в следствие, этот червяк засел в головах и правит там бал.
>Оно вполне определённое, это разыменоввывание нулевого указателяСишные апологеты как всегда не просто некомпитентны, а откровенно лживы. Вот простейший контрпример:
a = NULL;
i = 100500;
a[i] = 1;
Если 100500 не хватит, возьмите число побольше. Ну как?
>что это UB так как стандарт языка не может устанавливать ограничения на архитектуруUB - это сишность головного мозга, позволяющая компилятору произвольным образом изуродовать код. И сказать, как в конкретном случае это будет работать - невозможно.
>UB - это сишность головного мозгаТолько в вашей голове.
>позволяющая компилятору произвольным образом изуродовать код
И какие претензии к языку? Компилятор сделали слишком умным, вот да. Юзайте -O0, уродовать не будет.
И ещё, по там по ссылкам хорошие статьи на хабре. И основная тема в них - "компилятор слишком мудрый". А не "UB такой плохой".
>Компилятор сделали слишком умным, вот да. Юзайте -O0, уродовать не будет.Во-первых будет тормозить, во-вторых это всё равно не поможет.
>И основная тема в них - "компилятор слишком мудрый". А не "UB такой плохой".Не важно. В том примере, который я привёл, у нас сишный ub, сишнее некуда. Ибо целиком и полностью зависит от значения i - либо ошибка сегментации, либо порча памяти.
да откуда вы берётесь, не умеющие воображать то....мысленный (ибо лень на самом деле) эксперимент:
достаю VM с FreeDOS внутри, таки компилирую чем то ваш пример (с учётом 16-битной архитектуры), запускаю.
Ошибки сегментации нет. Порча памяти? Почему порча? Я так хотел.
Вы просто боитесь этого.
Undefined. Бу.
Или зациклены.
Сходите к психологу, что ли.
1. Макросы - не забывай скобки;
2. Указатели - assert;
3. Строки - о чём ты, в C есть строки.
>Макросы - не забывай скобки;Каким образом это исправит гигиену?
>Указатели - assert;Почему нет ошибки компиляции?
> Каким образом это исправит гигиену?Используй бумагу - "Каким образом это исправит гигиену?" - ТЫ же используешь бумагу?
То есть сам факт затенения имён переменных и не только, вас не смущает? При чём здесь вообще бумага?
Что за гигенические макросы? Это что на индуском?> невозможность статическим анализом в общем случае проверить отсутствие разыменновывания нулевого указателя
Ты несёшь какой-то откровенный бред. Просто написал какие-то рандомные слова с умным видом. В общем случае (и в частном тоже) стат.анализатором проверить отсутствие разыменновывания нулевого указателя можно. Ну ты походу просто никогда им не пользовался, поэтому и решил так опозориться.
> отсутствие строк даже в 2025 году
Покажи мне в ассемблере строки в 2025 году.
> Давайте апологеты си, объясняйте.
Да иди ты нахер
> разыменновывания нулевого указателя... является безопасной операцией, программа безопасно упадёт. Никаких утечек персональных данных не будет. Всё по расту.
>Что за гигенические макросы? Это что на индуском?В гугле забанили?
>В общем случае (и в частном тоже) стат.анализатором проверить отсутствие разыменновывания нулевого указателяВот сишники очень любят рассказывать, как у них всё работает. Вот мне сказали, что есть целых два флага для проверки, а они оба почему-то не работают.
cat b.h
```
struct A {
int* p;
};void set_null(struct A*);
int print(struct A*);
```
cat b.c
```
#include "b.h"void set_null(struct A* a)
{
a->p = 0;
}int print(struct A* a)
{
int* x = a->p;
return *x;
}
```
cat a.c
```
#include <stdio.h>
#include "b.h"int main()
{
int y = 7;
struct A a = {.p = &y };
printf("%d", print(&a));
set_null(&a);
printf("%d", print(&a));
return 0;
}
```
gcc -fanalyzer b.c -c -o b.o && gcc -fanalyzer a.c -c -o a.o && gcc -fanalyzer a.o b.o -o a && ./a
Segmentation fault (образ памяти сброшен на диск)
----
```
int test(int* x)
{
return *x;
}int main()
{
int *x = 0;
return test(x);
}
```
gcc a.c -Werror -Wnull-dereference
---
Превосходная работа сишного анализатора - малейший рефакторинг и проверка ошибок молча отваливается.
>Покажи мне в ассемблере строки в 2025 году.Покажите мне код на ассемблере, не в виде вставок или демок в 2025 году.
А, ты про этот анализатор - да это шляпа. Возьми нормальный standalone анализатор, он все находит.
>Возьми нормальный standalone анализатор, он все находит.Вот интересно, а почему это настоящие сишники не используют нормальный анализатор? Вот пришёл бы настоящий сишник в ядро, libpng и так далее, подключил бы нормальный анализатор, да и показал бы, что раст не нужен. Но вот только этого почему-то не случается.
1. А вообще я посмотрел на твой код... скажи честно, ты ведь хеллоуворлды на раст пишешь, верно? Почему у меня в set_null() используется 0 вместо NULL?> 2. Вот мне сказали, что есть целых два флага для проверки
Это вопросы к тем, кто тебе это сказал, уточняй у них. Но если тебе правда интересен ответ, то стат.анализатор анализирует код во время компиляции, а не во время его работы. Правда растафили таких подробностей не знают потому что им некогда - им надо div'ы выравнивать по центру. Но ты всегда можешь добавить санитайзеров к своему корявому примеру: -fsanitize=address вместо -fanalyzer
3. Статические анализаторы выстраивающие дерево исполнения и как следствие способные отловить null-ptr-deref в коде после изменения указателя, все же существующи. Можешь из погуглить.
>хеллоуворлды на раст пишешь, верно?Нет, не на расте и не хелловорлды. Надеюсь ответил на ваш вопрос.
>Почему у меня в set_null() используется 0 вместо NULL?Мне лень изучать 100500 разных языков ради того, чтобы писать сообщения на формуме. И потом, gcc против этого ничего не возражает. Я ж не на haskell пишу. Код работает как ожидается - работает.
>Это вопросы к тем, кто тебе это сказал, уточняй у них.Какой хороший диалог с сишниками - это предыдущие сишники(на форуме, в коде ядра, в коде браузера) неправильные, вот я - правильный сишник. Ну а в следующей теме выходит новый сишник и обвиняет в некомпетености уже этих.
>Но ты всегда можешь добавить санитайзеров к своему корявому примеру: -fsanitize=address вместо -fanalyzerАга, и падать во время выполнения, как в динамически типизированном питоне. Постойте, так си и есть динамически типизированный язык, с его void*
>Статические анализаторы выстраивающие дерево исполнения и как следствие способные отловить null-ptr-deref в коде после изменения указателя, все же существующиКак и единороги, не даром же про них столько легенд ходит. Но вот на улице их не встретить, да.
> Постойте, так си и есть динамически типизированный язык, с его void*хз что ты тут кривляешься, но по такой логике и ассемблер это динамически типизированный язык с его регистрами, где что угодно лежит (нет, там просто байты как и в Си)
>но по такой логике и ассемблер это динамически типизированный языкВНЕЗАПНО
> Покажите мне код на ассемблере, не в виде вставок или демок в 2025 году.Вас же, типа, в ядро допустили. В чем проблема посмотреть *.S в linux/arch/*
С - это кукурузник
Rust - это современный БоингЗдесь я вижу только два варианта. Или диверсия со стороны СИшников, или низкая квалификация программиста. Rust, как язык решающий определенные проблемы, здесь не причем. Если все таки низкая квалификация, то человек просто переводя Боинг на ручное управление (unsafe), не справился с задачей
С - это как раз Боинг, где всё делается руками, а Rust - это Airbus, где даже штурвала нет, только джойстик. Это две разные идеологии со своими достоинствами и недостатками, которые сосуществуют параллельно.
Ну ок, пусть будет так. Так тоже неплохо смотрится
Так ведь это же миссия Раста, спасать от ошибок из-за низкой квалификации программистов. Всё? Миссия провалена? Не долго музыка играла..
> Rust - это современный Боингкак Boeing 737 MAX 8 - два новейших борта всмятку
> как Boeing 737 MAX 8 - два новейших борта всмяткуА стопроцентной безопасности никто не обещал ;)
Ага. Двигатели переделывать денег нет. Корпус переделывать денег нет. Давайте просто на старый корпус двигатели побольше поставим.В штопор сваливается? Не беда - мы программно ограничим допустимое использование.
Ой! Облажались... И кто это сделал?
rust точно такой же
Самый рофл в том, что новость-не-читатели-ссылко-не-открыватели улюлюкают вокруг "это было в unsafe", а по факту виноват был "safe" код в Node::release, потому что какой-то гений решил сделать копию структур в листе, потому что "память бизапасна", снять лок с листа и начать итерировать его, пока другая часть кода подбирает этот лок и удаляет объект, я так понимаю вместе со всем его содержимым, которое себе скопировал код с Node::release.Боров чекеры, что с лицом?
Причём это буквально ошибка стиля
struct A { int a; };
struct list_of_A { struct list_of_A *next; struct A *data; }
...
// спавним элемент листа
struct A *it = list_add(list_head)->data = alloc(*it);
it->a = 42;
...
// код, который делает копию объекта из листа
struct list_of_A *li;
for (li = list_head->first; li; li = li->next) {
if (li->data->a == 42) break;
}
if (li) other_object->my_A = li->data;
...
// код, который не знал, что указатель на данные не уникальный
struct list_of_A *li, **prev_next;
li = list_head->first;
prev_next = &list_head->first;
while (li) {
if (li->data->a % 2) {
free(li->data);
li = *prev_next = li->next;
} else {
prev_next = &li->next;
li = li->next;
}
}
...
// код, который крашит ядро, будучи написанным на расте
if (other_object->myA.a == 42) ...
Правка: в конце вместо "myA." должно быть "myA->", потому что myA - адрес, а не сам объект. Компилятор выдаст ошибку для оператора точки на указателе.
Combined with threads using the unsafe remove method on the original
list, this leads to memory corruption of the prev/next pointersunsafe { node_inner.death_list.remove(self) };
Ну и где тут safe?
Вот тут:"""
And unfortunately that is exactly what is happening here. In
Node::release, we:1. Take the lock.
2. Move all items to a local list on the stack.
3. Drop the lock.
4. Iterate the local list on the stack.Combined with threads using the unsafe remove method on the original
list, this leads to memory corruption of the prev/next pointers.
"""Node::release скопировал память, пользуется копией в стаке, а обращение к освобождённой памяти один хрен случилось. Ой, а как так, всё же безопасно было!
> Node::release скопировал память, пользуется копией в стаке, а обращение к освобождённой памяти один хрен случилосьТак это что получается, что даже мейнтейнеры ядра уже ничего не понимают, что там в том ведре происходит?
Посмотри на количество коммитов, которые шлют эти ваши гулуголы, нвидии, интелы и амд, потом накинь сверху код для файловых систем, для сетевух, переписанные уже готовые драйвера (которые ни одна коммитящая гадина не тестила на том железе, для которого они пишут, максимум смотрят что компиляция проходит) и задайся сам себе вопрос - будь ты мейнтейнером, у тебя было бы время перепроверять за каждым индусом, чё он там понаписал? Поищи интервью с тем же Грегом, посмотри, сколько он всего мейнтейнит и как сильно он хочет чтобы кто-нибудь это ещё делал. Могли бы челы в гугле поставить своего ответственного главразраба мейнтенером, раз уж они так сильно зависят от ядра в том же ведроиде? Да запросто. Только у них видимо таких компетентных сотрудников нету, и на зп сажать чела, который будет проверять код того же интела - жаба душит, видимо.
> и на зп сажать чела, который будет проверять код того же интела - жаба душит, видимоАга. Корпоративная культура. Почитал как-то от опус одного из разработчиков компиляторов, как он в Интел интеловский компилятор разрабатывал и как пытался туда поддержку других процессоров (не интеловских) добавить. И как он ушел потом в гугл и начал поливать от туда помоями интел.
> мейнтейнеры ядра уже ничего не понимаютНу да, им же сказали, что язык безопасный, зачем что-то понимать?
> Combined with threads using the unsafe remove method on the original list...Тролль писать, тролль не читать.
Практика - критерий истины.
нет, доказательство - критерий истины!
Вот и подъехала безопасность. Предрекаю что когда Linux перепишут на Rust, то в плане всяких уязвимостей будет всё почти так как же как если бы на Rust не переписывали а всю эту темку с безопастностью Rust по тихому заметут под ковёр и поднимут на знамя какую-нибудь другу фичу языка.
> когда Linux перепишут на RustЛинукс будет лежать, не вставая.
... потому что под коврик (нижние слои) замели все unsafe в Rist
Раст не являетесь более безопасным языком чем Си. Безопасных языков нет. Но Си приучает программиста думать. Раст отучает это делать, и данная ошибка это подтверждает. Иными словами - думать надо на любом языке программирования!
> Раст не являетесь более безопасным языком чем СиВремя покажет! Я пока для себя разбираюсь с Rust потихоньку и ещё сам не понял, так это или нет
> думать надо на любом языке программирования!
Тут не поспоришь. Вон binder программист не подумал и получил race condition
Когда уже у вас кончатся запасы копиума?..> Раст не являетесь более безопасным языком чем Си
Является, т.к. по умолчанию нельзя разименовывать указатели, писать в одну и туже память из разных потоков, выходить за границы массива и т.д.
> Безопасных языков нет
Вот это откровение! Однако же, на C нужно постараться, чтобы не прострелить себе ногу, а на том же Haskell нужно постараться, чтобы прострелить — сишным кодом через FFI 😂
> Си приучает программиста думать
Уже больше 50 лет как приучает, а программист всё равно, независимо от уровня экспертизы, продолжает лепить одни и те же баги, которые просто невозможны в большинстве ЯП. Опеннетчики, разумеется, валят всё на skill issue, но при этом сами постоянно лепят такие же баги и поэтому никогда не показывают свой гениальный код. За десять лет всего один такой гений поделился своим кодом, и я при первом же запуске увидел вывод мусора в консоль, потому что автор кода невнимательно читал man page. Долго вам ещё нужно думать, чтобы додуматься писать идеальный код, который пока что существует только в ваших грёзах?
> Раст отучает это делать
Раст как раз-таки приучает думать, только не над тем, как правильно брать в руки битое стекло, чтобы отрезать хлеб вместо пальца, а как использовать более подходящие инструменты для нарезки хлеба.
> думать надо на любом языке программирования
Очередное откровение. Да ты — философ.
Завязывай с копиумом, Иванушка.
Всему есть объяснение
https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...
Очень интересный годовой отчёт, показывает, что команда занимается делом.
И это только чуть-чуть переписали... А если всё перепишут, то получится такой сарай с сюрпризами - что мама не горюй!
Переписывать ядро на сыром языке - это ж надо было додуматься!
> на сыром языкена сыром 20-летнем языке (с 2006)... Он уже не сырой, а "немного" пахнет.
> на сыром языкеА можно мне объяснить, в чем его сырость? В данном случае вина погромиста, а не самого языка
В отсутствии ISO
А что, если Линус специально пропустил этот баг, чтобы выкинуть раст из ядра, а на плач растоманов всякий раз тыкать в этот баг пальцем :D