В вошедшем в состав ядра 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 уязвимостей.
И это ещё не предел!
Он как бы unsafe как раз потому, что раст без него не может ничего
А зачем тогда язык, который всегда unsafe?
по идеи надо писать любой код так, что бы всё работало правильно и безопасно хдд. правильно хартман говорит
В ядре пока с этим проблема, потому что сами разработчики ядра не всегда способны сказать как определённые апи правильно использовать, ничего внятнее "делайте как другие делают"
>>Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, написал, что Rust не является панацеей, позволяющей избавиться от всех проблем безопасности, но данный язык действительно помогает защититься от определённого класса уязвимостей.инстант демедж контрол.
Объявлено начало эпохи постоянного падения ядер линукса.
Они хотя бы попытались переписать…
Так можно и на Си переписать, зачем Rust, если всё равно гарантий нет.
Логика уровня:
"Зачем вам ремни и подушки если от столкновения с Камазом это не защитит!"Вы случайно не на СИ пишете)?
> Логика уровня:"Зачем вам ремни и подушки если от столкновения с Камазом это не защитит!"
Лигика. Зачем вам ремни если вы только и делаете, что их отстегиваете, что бы вручную в коробку передач залезть, для замены передаточного числа.
> Лигика. Зачем вам ремни если вы только и делаете, что их отстегиваете, что бы вручную в коробку передач залезть, для замены передаточного числа.Ну так нет еще нормальной коробки.
Зато простое открытие двери не отрезает водителю ноги.Мне не нравятся аналогии с автомобилями, тк я езжу на метро.
Давайте лучше сравнивать с унитазами?
Ну так вот - унитаз локализует овно в квартире.
Как и unsafe в коде.
> Зачем вам ремни если вы только и делаете, что их отстегиваетеЛожная аналогия. Процент ансейф кода в ядре сильно меньше 5. Процент ансейф кода в юзерспейсе сильно меньше 1.
Процент ансейф кода в С - 100.
> Процент ансейф кода в С - 100.Так это про любой ЯП можно сказать, в том числе про Ржавого.
И да, прежде чем вы продолжите нести чушь, предъявите пожалуйста код написанный лично вами. Чтобы мы имели представление о квалификации "критика".
> Так это про любой ЯП можно сказать, в том числе про Ржавого.Вот это квалификация!
Вы программированию в каком колхозе учились?
> предъявите пожалуйста код написанный лично вами.
Хм, а чего еще потребуете?
> Чтобы мы имели представление о квалификации "критика".
Думаю код вам не поможет, тк ваша квалификация на уровне дна.
>> Так это про любой ЯП можно сказать, в том числе про Ржавого.
> Вот это квалификация!
> Вы программированию в каком колхозе учились?
>> предъявите пожалуйста код написанный лично вами.
> Хм, а чего еще потребуете?
>> Чтобы мы имели представление о квалификации "критика".
> Думаю код вам не поможет, тк ваша квалификация на уровне дна.Ну т.е. вы расписываетесь в своей полной некомпетентности в программировании. А значит ценность вашего мнения по данному вопросу - нулевая. Хорошо, спасибо, больше вопросов не имею.
смысл что оплошности компилятор не пропустит на расте. а если уж лезть за забор - так уж точно будет видно что куда и откуда.
Суть новости: в байндере на расте целая 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
Вам нужно - вы и пилите.> Или "нет кода - нет уязвимостей"?
Уязвимость может быть в алгоритме.
Даже кода нет, а уязвимость есть.
> Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен, сели в лужуЕсли одна растовая CVE - это "сели в лужу", то куда сели сишочники со своими 159 CVE? 🤔
> Если одна растовая CVE - это "сели в лужу", то куда сели сишочники со своими 159 CVE? 🤔Все верно.
Растовики сели.
А сишники из нее и не подымались))
Это не CVE со взломом рута, а Deny-Of-Service в худшем случае.
Там все эти ошибки не являются настоящими серьезными CVE и ни к чему серьезному привести не могут.
> Проблема вызвана состоянием гонки при выполнении операций в блоках 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
Какое именно правило форума нарушили мои предыдущие сообщения?
Нет ли тут можераторского произвола?
привыкай, тут так принято, это называется свобода слова, слова свободные, но писать их тут ты не можешь
Та ладно, я понимаю что есть правила.
Откровенное хамство, политоту, оскорбления - нужно пресекать.Но вон например выше чквак вбросил про 0.6% откровенное вранье, но его не удалили.
>вчера были опубликованы сведения о 159 уязвимостях в различных компонентах ядра Linux, написанных на языке Си.Это предложение пахнет желтизной. Си - это рабочая лошадка. Закрытие уязвимостей обычнная работа, не надо тут раздувать из мухи слона.
Для системного программирования нет ничего лучше чистого Си.
> Си - это рабочая лошадка.Старая и дряхлая.
> Закрытие уязвимостей обычнная работа, не надо тут раздувать из мухи слона.
А написание уязвимостей? Тоже обычная работа?
Тут целая новость из-за ОДНОЙ ошибки в расте, а 150 в СИ мало кого волнуют.> Для системного программирования нет ничего лучше чистого Си.
По мнению кого?
Вон разработчики ядра решили что это не так.
У вас есть более высокии компетенции?
целая новость потому что растосектанты с двумя извилинами (одна чтобы кричать "безопасно", другая чтобы кричать "луддиты") заспамили весь интернет маркетинговыми лозунгами мозилы, поэтому их полезно спускать на грешную землю. никто не любит упоротых фанатиков с NIH-синдромом, поэтому их очередное попускание и собирает столько плюсиков.и добавить раст - не решение разработчиков а повеление американской гебухи в лице nsa от 10 ноября 2022 года, ты ещё скажи что российские кабанчики в едином порыве решили добавить mitm-сертификат от минцифры потому что у кабанов такая компетенция высокая.
> целая новость потому что растосектанты с двумя извилинами (одна чтобы кричать "безопасно", другая чтобы кричать "луддиты") заспамили весь интернет маркетинговыми лозунгами мозилы,А... т.е дыр в СИшке не было.
А что ж тогда за 150 штук прям в этой же новости?> поэтому их полезно спускать на грешную землю. никто не любит упоротых фанатиков с NIH-синдромом, поэтому их очередное попускание и собирает столько плюсиков.
Это как раз логично.
Пенек был всегда местом нетакусков, которые к программированию отношения не имеют.
Но покуракекать им полезно.
Все равно их мнение в ядре не котируется.
> и добавить раст - не решение разработчиковКакой ужас! А чье же тогда?
> а повеление американской гебухи в лице nsa от 10 ноября 2022 года,
Заговор! Злое NSA не хочет чтобы программы были дырявые!!
> ты ещё скажи что российские кабанчики в едином порыве решили добавить mitm-сертификат от минцифры потому что у кабанов такая компетенция высокая.
Чо? Ты что пьяный?
вот и миллионы индусов так говорят, пуляя новые ежемесячные апдейты на винду
> Закрытие уязвимостей обычнная работаКак, собственно, и их создание...
> напрямую работающих с указателями на предыдущий и следующий элементы спискаЭлементарный список не осилили. Какая же жесть должна быть в структурах посложнее.
так все опытные пограмисты новый язык уже где-то с середины книжки изучать начинают, пропуская вводую воду
Это язык в котором элементарный список без unsafe не делается.
> Это язык в котором элементарный список без unsafe не делается.Пф, а на СИ или плюсах это список будет safe? Или нет?
Дырявые ЯП unsafe полностью, от первой строчки до последней.
Найди реализованный в ядре список с проблемами у указателями.Их там тысячи, если что. И намного сложнее. Просто вся логика для восприятия проще.
> Найди реализованный в ядре список с проблемами у указателями.Абсолютно любой, который не thread-safe. Ты же в новости читал, что проблема в состоянии гонки, а не в самой логике работы списка?
падажжи, так а зачем они закодили состояние гонки на безопасном расте?
Неважно, они и не пиарились, как безопасные. Важно, что МИФ о безопасности Раста развеивается практическими примерами.
> Неважно, они и не пиарились, как безопасные.Ты доку открывал?
Видел где даются гарантии?
Чего тогда бухтишь?> Важно, что МИФ о безопасности Раста развеивается практическими примерами.
Хахаха, миф у тебя в штанишках.
А тут есть докуументация, которую войны-супротив-раста, естественно не читали, зато куракекают про миф.
Ты очевидно с голосами в своей голове говоришь.>> Неважно, они и не пиарились, как безопасные.
> Ты доку открывал?
> Видел где даются гарантии?
> Чего тогда бухтишь?Он о Си говорит, очевидно.
>> Важно, что МИФ о безопасности Раста развеивается практическими примерами.
> Хахаха, миф у тебя в штанишках.
> А тут есть докуументация, которую войны-супротив-раста, естественно не читали, зато куракекают про миф.Совсем не очевидна связь между документацией и наличием мифов. От слова абсолютно. Если ты хоть раз открывал документацию на развивающуюся системы, то видел, что документация часто описывает то что было реализовано поколение или два назад. Поколение - это смена архитектуры.
> Он о Си говорит, очевидно.А кто тогда пиарился?
> Совсем не очевидна связь между документацией и наличием мифов. От слова абсолютно.
Конечно.
Тут приходят неграмотные сишники и начинают вещать какие-то выдуманные вещи.
Типа "вы обещали безопасность везде!!!"
> А кто тогда пиарился?Ответ очевиден. И это так оно и есть. Ибо именно этим обосновывали приём в ядро.
> Тут приходят неграмотные сишники и начинают вещать какие-то выдуманные вещи.
> Типа "вы обещали безопасность везде!!!"Ну. Уж элементарные структуры данных в безопасном языке должны быть безопасные.
Когда говорят "очевидно", то скорее всего врут.
Может цитату приведете?
Думаю там будет что-то вроде "позволяет избавиться от некоторого класса ошибок".Вот видос с Greg Kroah-Hartman
youtu.be/HX0GH-YJbGw?t=583
цитирую " Rust is not a silver bullet.
But, so just please take that away.
Memory safety doesn't mean there's never any memory errors."> Ну. Уж элементарные структуры данных в безопасном языке должны быть безопасные.
Вооот!
Сам выдумал, теперь пытаешься натянуть сову на глобус.
> Сам выдумал, теперь пытаешься натянуть сову на глобус.Мало ли что он не гарантировал. Суть-то в том, что без таких гарантий от него пользы как с козла молока.
> Мало ли что он не гарантировал.Лол, т.е ты напридумывал какой-то чушни, а теперь разачарован?
> Суть-то в том, что без таких гарантий от него пользы как с козла молока.
Ваше мнение настолько важно для разработчиков ядра, что можете засунуть его...
Твоя компетенция позволяет оценивать пользу?
Или это очередное "я решил что должно быть так!!"
> Ваше мнение настолько важно для разработчиков ядра, что можете засунуть его...
> Твоя компетенция позволяет оценивать пользу?
> Или это очередное "я решил что должно быть так!!"Ты новость читал?
Если так то объясни откуда уязвимость?
А вы новость читали?> Если так то объясни откуда уязвимость?
Из unsafe блока.
> Из unsafe блока.Отвечу тут. В этом и проблема!
Элементарный список - требует usafe. Ядро - это огромная, постоянно меняющаяся сложная структура данных. Там будут сплошные unsafe.
> Элементарный список - требует usafe.Так на СИ любой список тоже unsafe.
Я скажу больше, вообще любой код!> Ядро - это огромная, постоянно меняющаяся сложная структура данных. Там будут сплошные unsafe.
Конечно будут.
Любое взаиможействие с кодом на дырявых языках может быть только через unsafe.
> Так на СИ любой список тоже unsafe.
> Я скажу больше, вообще любой код!Так они и не входили в разработку ядра как безопасный язык.
> Конечно будут.
> Любое взаиможействие с кодом на дырявых языках может быть только через unsafe.Это тоже. Но в ПЕРВУЮ очередь они будут из-за того, что даже элементарные контейнеры в rust будут unsafe. Любая сложная коллекция - тем более.
И с таким языком по-другому быть не может.
> Так они и не входили в разработку ядра как безопасный язык.Не очень вижу в чем противоречие.
Как говорил Грег
Memory safety doesn't mean there's never any memory errors. Just means you're going to crash and that's fine.> Это тоже. Но в ПЕРВУЮ очередь они будут из-за того, что даже элементарные контейнеры в rust будут unsafe.
А каких элементарных контейнеров не хватает?
> Любая сложная коллекция - тем более.
Звучит бездоказательно.
> И с таким языком по-другому быть не может.
Тоже как пальцем в небо)
Тут основная фишка в том, что у тебя лист может быть с unsafe (хотя на гитхабе есть примеры и без него), а весь код его использующий проверяется.
> Не очень вижу в чем противоречие.Противоречие простое. У языка в качестве преимущества преподносится безопасность. Но та что есть в языке может работать только в небольшой сложности работе без сложных структур данных.
> А каких элементарных контейнеров не хватает?
Всех. Дай реализацию списков без unsafe.
> Тут основная фишка в том, что у тебя лист может быть с unsafe (хотя на гитхабе есть примеры и без него), а весь код его использующий проверяется.
Есть. Но не читаемый.
И вся фишка в том, что работа в ядре - это или работа со сложными структурами или работа с железом.
Лишь немного фильтры данных и их перекладывание.
> У языка в качестве преимущества преподносится безопасность. Но та что есть в языке может работать только в небольшой сложности работе без сложных структур данных.Сложная структура это что?
Проблем только со списками т.к там множественное владение.> Всех. Дай реализацию списков без unsafe.
doubly-linked list подойдет?
gist.github.com/matey-jack/3e19b6370c6f7036a9119b79a82098ca> И вся фишка в том, что работа в ядре - это или работа со сложными структурами или работа с железом.
> Лишь немного фильтры данных и их перекладывание.Сколько в ядре было ошибок в банальных строках?
Или с Signed integer overflow или buffer overflow?
Или с "мы кидали ошибку через -1, потом что-то пошло не так"?Типа этой "Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables и ksmbd "
opennet.ru/opennews/art.shtml?num=60860
"Проблема связана с ошибкой в функции nft_verdict_init(), которая допускает использования положительных значений в качестве кода ошибки"
> Сложная структура это что?
> Проблем только со списками т.к там множественное владение.И с графами?
И несколькими видами и деревьев?
Да там практически все структуры динамически меняющиеся и поэтому (в идеологии rust) со множественным владением.
> doubly-linked list подойдет?
С рекурсией?
Э... в ядро?
> Сколько в ядре было ошибок в банальных строках?
> Или с Signed integer overflow или buffer overflow?
> Или с "мы кидали ошибку через -1, потом что-то пошло не так"?Ну. Тут rust поможет. Но ради этого использовать отдельный язык....
> И с графами?
> И несколькими видами и деревьев?Хм.. а у нас сильно отличается например линейный однонаправленный список от вырожденного дерева?
На СИ все эти структуры (и вообще все остальные) будут так же unsafe/> С рекурсией?
> Э... в ядро?Думаете будет хуже чем сейчас?))
> Ну. Тут rust поможет. Но ради этого использовать отдельный язык....
Потому что не осилили по другом.
Предложите что-то лучше.В моем сообщении была ссылка на повышение привилегий, как раз по причине "мы передавали ошибку через результат функции".
> Хм.. а у нас сильно отличается например линейный однонаправленный список от вырожденного дерева?
> На СИ все эти структуры (и вообще все остальные) будут так же unsafe/Так весь вопрос что вся работа, практически в этом состоит. В манипуляции такими структурами.
> Думаете будет хуже чем сейчас?))
Это принципиально неприемлемо. Для рекурсии стек использовать нельзя.
> Потому что не осилили по другом.
> Предложите что-то лучше.Есть разные реализации. В ядре с этим сложнее.
Но в обычных проектах проблема только там, где старый стиль кодирования остался с доисторических времён. Если проект разрабатывают в соответствии с новыми guidelines (лучшими практиками) то таких проблем нет.
> Так весь вопрос что вся работа, практически в этом состоит. В манипуляции такими структурами.Далео не вся. Тут вы заведомо преувеличиваете.
> Есть разные реализации. В ядре с этим сложнее.
Но новость про ядро.
> Но в обычных проектах проблема только там, где старый стиль кодирования остался с доисторических времён. Если проект разрабатывают в соответствии с новыми guidelines (лучшими практиками) то таких проблем нет.
Я понимаю, что можно сделать проект на С23, обмазаться санитайзерами и фаззингом...
Но мы говорим про ядро, которое перешло на С11 в 2022 году, а до этого обходилось копролитным С89. Где патчи отправляются почтой, а CI не существует.Так вот, какие есть реалистичные предложения чтобы избавиться от части ошибок?
> Далео не вся. Тут вы заведомо преувеличиваете.Не вся. Но заведомо большая часть, если учесть ещё работу с железом.
> Так вот, какие есть реалистичные предложения чтобы избавиться от части ошибок?
Так и этот не реалистичный. Если внедрение C11 было только 2022, то почему rust начали внедрять, пока он еще сырой? В ядре даже не текущий rust используют, а старые версии с кучей переделок.
Спрашивается. Где логика. Я вижу только одну. Как с системой контроля версий BitKeeper. Посмотреть как сделали другие и сделать свое. Правильное.
> Не вся. Но заведомо большая часть, если учесть ещё работу с железом.Но дрова на нем пишут.
И они даже работают.
>> Так вот, какие есть реалистичные предложения чтобы избавиться от части ошибок?
> Так и этот не реалистичный.Раст в ядре только-только из "экспериментального" статуса вышел.
Реалистичность будет видна через пару лет.> Если внедрение C11 было только 2022, то почему rust начали внедрять, пока он еще сырой?
> В ядре даже не текущий rust используют, а старые версии с кучей переделок.Потому что это самый классный момент.
Можно подправить сам язык, под свои хотелки.
Сказать "хотите попасть в ядро? вот вам список изменений".
Провернуть подобное когда уже есть стандарт, сертификации, написано куча кода - почти невозможно. Только если сделать свой диалект, который будет жить только в ядре.
Как вендорлокнутые расширения ГЦЦ,> Спрашивается. Где логика. Я вижу только одну. Как с системой контроля версий BitKeeper. Посмотреть как сделали другие и сделать свое. Правильное.
Не очень уловил, что вы хотели сказать.
Обычно "сделать свое, правильное" заканчивается "теперь у нас 15 стандартов".
> Не очень уловил, что вы хотели сказать.
> Обычно "сделать свое, правильное" заканчивается "теперь у нас 15 стандартов".Git же сделали.
Кто мешает сделать свой компилятор? Если, конечно, не прислушаются.
> Git же сделали.Сложность отличается на порядок.
А может и на 2.> Кто мешает сделать свой компилятор? Если, конечно, не прислушаются.
А зачем если можно взять готовый и подпилить под себя?
> Сложность отличается на порядок.
> А может и на 2.Git - десятки миллионов строк
rust - десятки тысяч строк
> А зачем если можно взять готовый и подпилить под себя?
И ввести то, чего сильно не хватает, но ломает все текущие проекты. И наконец-то сделать систему владения учитывающую коллекции.
> Git - десятки миллионов строкТут облажался. :)
> И ввести то, чего сильно не хватает, но ломает все текущие проекты.
> И наконец-то сделать систему владения учитывающую коллекции.Что-то мне подсказывает, что растовики не из вредности не учитывают коллекции в системе владения)
А просто сейчас нет возможности (алгоритмов) для реализации такой хотелки.
Вангую что как только будет возможность - это сразу же добавят в раст.
Project Verona:Региональное владение (Linear Regions): В отличие от Rust, где владение отслеживается на уровне каждого отдельного объекта, Project Verona оперирует группами объектов (регионами). Это позволяет управлять целыми коллекциями объектов как единым целым.
Решение проблем «графов» объектов: В Rust создание циклических структур данных или сложных графов затруднено из-за строгих правил заимствования (borrow checker). В Verona объекты внутри одного региона могут свободно ссылаться друг на друга, а безопасность проверяется на уровне границ всего региона.
Изоляция и конкурентность: Программа делится на изолированные регионы. Только один поток может иметь доступ на запись к конкретному региону в любой момент времени, что исключает состояние гонки (data races) без необходимости сложной синхронизации каждого объекта.
> Project Verona:Да, это интересный проект, я про него читал лет пять назад.
К сожалению он кажется уже мертвый или стремится к такому состоянию.
В репозитории активности почти нет.Обещают массивный рефакторинг, но это было 2 года назад.
The project is not ready to be used outside of research, and is under going a massive refactoring.Боюсь или они лишились финансирования, или столкнулись с непреодолимыми трудностями.
Жаль, но такое часто случается.Зато честно пишут
Project Verona is a research language that is inspired by ideas from other languages:
Rust
Cyclone
Pony
Хахаха, а ведь смешно облажались 😂
Радует только что в ансефе, а то совсем неудобно бы было.Впрочем, за свои действия нужно отвечать.
Готов принять лучи ненависти как топящий за раст.
> Хахаха, а ведь смешно облажалисьТы вот про этих? Настолько смешно, что уже даже не расписывают в новости, что опять накосолапили Сишники.
> вчера были опубликованы сведения о 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 тогда зачем? :)
То есть, ошибка в той части ядра, на которую тут регулярно ссылаются при попытках доказать безопасность Rust? Google тоже дилетанты как и Cloudflare получается?
> То есть, ошибка в той части ядра, на которую тут регулярно ссылаются при попытках доказать безопасность Rust?Ээээ? Андроид еще использует страый биндер.
Ты чего-то попутал.> Google тоже дилетанты как и Cloudflare получается?
Так все ошибаются! Именно поэтому нужно вводить автоматические проверки.
Эта ошибка как раз показывает "нужно улучшать инструменты".
>Эта ошибка как раз показывает "нужно улучшать инструменты".Вот с этим соглашусь. При должном развитии статических анализаторов надобность в Rust отпадёт сама собой. Радует, что в этом направлении есть подвижки.
> Вот с этим соглашусь. При должном развитии статических анализаторов надобность в Rust отпадёт сама собой.А зачем было ждать 10-20 лет, пока не начали раст изобретать?))
> Радует, что в этом направлении есть подвижки.
Медленные, это к сожалению, раз.
А два - пока подвижки недостаточные. Ни один из стат анализаторов не дает такие проверки владения.
> А зачем было ждать 10-20 лет, пока не начали раст изобретать?))Не совсем так. Пока лобби не начало пропихивать требования госконторы.
До этого проблема не воспринималась, серьезной. Для этого, идеологически, лучше подходит изменение архитектуры железа, чем компилятора.
Требования пропихнули.
Ну, надо крутиться.
> Не совсем так. Пока лобби не начало пропихивать требования госконторы.Причем тут госконторы?
Или программистам ядра было норм что у них куча ошибок, а в некоторых случаях еще и RCE, повышение привилегий и тд?
Постоянное игнорирование последнего, так вообще попахивает саботажем или бекдорами.> До этого проблема не воспринималась, серьезной.
Ну, т.е пока ГОС не стукнет, программеру было побоку?
> Для этого, идеологически, лучше подходит изменение архитектуры железа, чем компилятора.
Не правда.
Они только добавляли уязвимости основанные на спекулятивном исполнении, всякие спектры и мелтдауны.
ChkTag начали стандартизировать буквально сейчас.Т.е просто всем было пофиг.
Шо, опять?
Не опять, а снова.
Ага, 159 раз опять. Бедные сишники...
Что-то мне кажется, что этот Диды СИшники специально так сделали, чтобы дискредитировать Rust. Там достаточно недовольных, так что такие диверсии могут теперь быть частыми
Сомнительно.
Биндер писали сотрудники гугла (aliceryhl@google.com)
За диверсию можно и партбилет положить на стол.
Такое только программисты на Rust могут сделать. В C ошибки скучные, а тут не смогли написать связный список!
>Такое только программисты на Rust могут сделать. В C ошибки скучные, а тут не смогли написать связный список!Так им всё равно надо Звезду Героя дать. На таком брейнфаке написать хоть что-то похожее на работающее.
> В C ошибки скучные"Не смогли посчитать размер строки" или "не смогли написать split строки" это скучная или нет?
> а тут не смогли написать связный список
Список они написали, а с локами запутались.
Даже приятно что первая уязвимость оказалась такая, а не унылая off-by-one error))
>Что-то мне кажется, что этот Диды СИшники специально так сделали, чтобы дискредитировать RustНе, сами, сами справляются
Да-да, конечно)) Во всём "деды-сишники" виноваты, а не Google, программисты которого даже на Rust не могут нормально писать. При этом Google же и ваш дружный хор его платных подпевал всё равно продолжают везде упорно рассказывать, что дело в языке программирования, да. А не в том, что кто-то нанимает людей с низкой квалификацией, сам никого не обучает и условия труда при этом как на галере.Нету, ребята, нету серебряной пули. И прибыли вам ничто не подымет - всё, планета кончилась. Да и вы скоро закончитесь, поэтому собственно так ожесточённо везде и лезете.
> Во всём "деды-сишники" виноваты, а не Google, программисты которого даже на Rust не могут нормально писать.Почему не могут? Могут.
Всего одна ошибка. Сравните это с 150 от дидов.> что дело в языке программирования, да.
Да, если вам врач предложит вырывать зуб пассатижами, а не специальным инстирументом, вы согласитесь?
> нанимает людей с низкой квалификацией,
А чего тогда есть ошибки в проектах, без корпораций?
Там никого не нанимают, а ошибки есть.> Нету, ребята, нету серебряной пули.
Конечно нету. Выше кидали цитату Грега Хартмана где он именно это и говорит.
Но "не серебьрянная пуля" и "лучше недоязыка из 70х" это разные вещи)> Да и вы скоро закончитесь,
Только после вас)
У меня будет отличная мотивация сплясать в комментах на вашей могилке.
Но делать этого я не буду, ну чтобы не уподобляться вам.
>[оверквотинг удален]
> А чего тогда есть ошибки в проектах, без корпораций?
> Там никого не нанимают, а ошибки есть.
>> Нету, ребята, нету серебряной пули.
> Конечно нету. Выше кидали цитату Грега Хартмана где он именно это и
> говорит.
> Но "не серебьрянная пуля" и "лучше недоязыка из 70х" это разные вещи)
>> Да и вы скоро закончитесь,
> Только после вас)
> У меня будет отличная мотивация сплясать в комментах на вашей могилке.
> Но делать этого я не буду, ну чтобы не уподобляться вам.Ссылочку на код, написанный лично вами, пожалуйста давайте. И только после этого продолжим.
> Ссылочку на код, написанный лично вами, пожалуйста давайте.А ключи от квартиры где деньги лежат не дать?)
> И только после этого продолжим.
Не, не стоит.
Вы тут человек известный, качество своего кода уже показали.
Как и свои безумные фанатазии.Можете и дальше ходить с плакатиком "Часики тикают!!!11"
>> Ссылочку на код, написанный лично вами, пожалуйста давайте.
> А ключи от квартиры где деньги лежат не дать?)
>> И только после этого продолжим.
> Не, не стоит.
> Вы тут человек известный, качество своего кода уже показали.
> Как и свои безумные фанатазии.
> Можете и дальше ходить с плакатиком "Часики тикают!!!11"Ясно. Вы расписываетесь в полном отсутствии у вас опыта программирования и соответствующих знаний. А значит ценность вашего мнения стремится к нулю.
> Ясно. Вы расписываетесь в полном отсутствии у вас опыта программирования и соответствующих знаний.Пф, логику вам кажется в школе не преподавали.
Вы случайно не на С/С++ пишете?> А значит ценность вашего мнения стремится к нулю.
Сказал человек не осиливший даже парсера.
>> Ясно. Вы расписываетесь в полном отсутствии у вас опыта программирования и соответствующих знаний.
> Пф, логику вам кажется в школе не преподавали.
> Вы случайно не на С/С++ пишете?
>> А значит ценность вашего мнения стремится к нулю.
> Сказал человек не осиливший даже парсера.Да-да-да...
>> Сказал человек не осиливший даже парсера.
> Да-да-да...Вижу что мы пришли к единому мнению.
За сим откланяюсь)
> За сим откланяюсь)Ну наконец то.
> Всего одна ошибка. Сравните это с 150 от дидов.Одна на 1000 строк кода в сравнении с 150 на пару миллионов - да нормально.
> А не в том, что кто-то нанимает людей с низкой квалификацией,
> сам никого не обучает и условия труда при этом как на галере.
> условия труда при этом как на галере.Что??? Это у гугла условия труда как на галере?!
Вы посмотрите какие у них условия труда и зарплаты!
Не пишите бред про то, что не знаете.Ну и про квалификацию вы тоже не правы. Если так рассуждать - то в ядре вообще нет квалифицированных разработчиков.
> Что??? Это у гугла условия труда как на галере?!
> Вы посмотрите какие у них условия труда и зарплаты!
> Не пишите бред про то, что не знаете.А что ж они тогда уязвимости втыкают?))
> Ну и про квалификацию вы тоже не правы.
Вопрос тот же.
> А что ж они тогда уязвимости втыкают?))Просто потому уязвимости не связаны с условиями работы.
А все ограничено физическими лимитами человека на внимательность.
Что в теории можно чуть-чуть подтянуть тренировками, но все равно найдется кодовая база с размером где любой человек не уследит.Просто джун запутается в 10 строчках, мидл в 100, а дед в 1000.
Но это гарантирова рано или поздно произойдет.
И мы собственно это наблюдаем с ростом размера кодовой базы ядра - связи становятся все запутаннее и неочевиднее.
> Просто потому уязвимости не связаны с условиями работы.
> А все ограничено физическими лимитами человека на внимательность.
> Что в теории можно чуть-чуть подтянуть тренировками, но все равно найдется кодовая
> база с размером где любой человек не уследит.Нанимайте/обучайте больше людей.
> Просто джун запутается в 10 строчках, мидл в 100, а дед в
> 1000.
> Но это гарантирова рано или поздно произойдет.
> И мы собственно это наблюдаем с ростом размера кодовой базы ядра -
> связи становятся все запутаннее и неочевиднее.Спасибо, кэп ;)
> Нанимайте/обучайте больше людей.Еще раз: это вам не поможет.
Вы можете хоть 100500 людей нанять, но сложность кодовой базы будет выше чем возможности каждого из них. Вы мне сейчас напоминаете менеджера, который думает что если взять 9 женщин, то за месяц появится новый ребенок.И обучение тоже не поможет.
Чему вы будете их обучать? Не выходить за границы массива? Правильно расставлять локи?
Так это знает даже первокурсник, а толку.
> Еще раз: это вам не поможет.
> Вы можете хоть 100500 людей нанять, но сложность кодовой базы будет выше
> чем возможности каждого из них. Вы мне сейчас напоминаете менеджера, который
> думает что если взять 9 женщин, то за месяц появится новый
> ребенок.Ну т.е. про инкапсуляцию вы не в курсе. Разделение труда тоже мимо вас прошло. В общем - не несите чушь.
> И обучение тоже не поможет.
> Чему вы будете их обучать? Не выходить за границы массива? Правильно расставлять
> локи?
> Так это знает даже первокурсник, а толку.Так, товарищ Умник, ссылку на код, написанный лично вами - в студию. И только после этого продолжим обсуждать хоть что-то, касающееся программирования.
Молодцы Диды значит.
а все потому что нужно писать программы на турбопаскаль и не выделываться
Ржавое (rust) дырявое (c) ведро (linux).
Стоит ли напомнить, что Binder - это из Андроида и для Андроида, т.е. принесли это гугловцы
>Rust не является панацеей, позволяющей избавиться от всех проблем безопасности, но данный язык действительно помогает защититься от определённого класса уязвимостей.а чтобы защититься от других классов уязвимостей, мы будем писать ядро на других языках! По одному на класс.
> а чтобы защититься от других классов уязвимостей, мы будем писать ядро на
> других языках! По одному на класс.Вот когда сможем защититься, тогда и поговорим.
Провести формальную верификация ядра невозможно.
Так что выбор не большой.Но если изобретут Раст-2.0, который закроет еще какой-то пласт дыреней - то то я только за выкинуть устаревший Раст)))
все фанатики раста - безграмотные. факт
Blazing fast CVE's! 😁
Memory safe CVE
introduced by vibrant community
Не introduced, а brought to you. Понимать надо.
примерная иллюстрация ситуации: https://i.ibb.co/FkvFWv95/image.png
какой к чертям binder? есть posix ipc
Гугловцы пилят себе для андроида. Вернее переписывают то что используют сейчас
Это безопасное CVE, я ж правильно понимаю?
> Это безопасное CVE, я ж правильно понимаю?Более менее.
Упало и слава богу.
Нашли, пофиксили.Страшное это RCE.
то чувство, когда язык купил, а программировать не купил
Если бы это было бы написано на раст то тогда было бы безопасно
ну а на кой этот ансейф? чтобы на него все и сваливать, мол падает и приводит к уязвимостям это не код на расте, а ансейф, на то и ансейф, епта а нах тогда раст нужен? если и так все всегда валили на Си? Не криворукий смузихлеб виноват, а ансейф.пс: хорошая причина оправдывания бекдоров, пихайте в ансейф и валите все на ансейф.
слово смузихлёб как-то оскорбляет председателя?
Джо-о-о-о-о!
> 159 уязвимостях в различных компонентах ядра Linux, написанных на языке Си.Ну так учитывая какой процент кода написан на Си то даже 1:159 по ошибкам будет не в пользу ржавого.
> Ну так учитывая какой процент кода написан на Си то даже 1:159 по ошибкам будет не в пользу ржавого.159 это за месяц.
Сколько там кода в ядро добавилось за этот период?
> в блоках unsafe, напрямую работающих с указателями на предыдущий и следующий элементы спискаРаст до сих пор не умеет даже в двухсвязный список?! 20 лет пилят, а такого базового примитива невозможно без unsafe сделать...
Самая смешная новость в этом месяце.