В вошедшем в состав ядра Linux 6.18 механизме межпроцессного взаимодействия Binder, написанном на языке Rust, устранена уязвимость (CVE-2025-68260). Проблема вызвана состоянием гонки при выполнении операций в блоках unsafe, напрямую работающих с указателями на предыдущий и следующий элементы списка. При успешной эксплуатации уязвимость в Binder ограничивается аварийным завершением и не приводит к повреждению памяти...Подробнее: https://www.opennet.ru/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 как раз потому, что раст без него не может ничего
по идеи надо писать любой код так, что бы всё работало правильно и безопасно хдд. правильно хартман говорит
В ядре пока с этим проблема, потому что сами разработчики ядра не всегда способны сказать как определённые апи правильно использовать, ничего внятнее "делайте как другие делают"
>>Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, написал, что Rust не является панацеей, позволяющей избавиться от всех проблем безопасности, но данный язык действительно помогает защититься от определённого класса уязвимостей.инстант демедж контрол.
Они хотя бы попытались переписать…
Так можно и на Си переписать, зачем Rust, если всё равно гарантий нет.
Логика уровня:
"Зачем вам ремни и подушки если от столкновения с Камазом это не защитит!"Вы случайно не на СИ пишете)?
> Логика уровня:"Зачем вам ремни и подушки если от столкновения с Камазом это не защитит!"
Лигика. Зачем вам ремни если вы только и делаете, что их отстегиваете, что бы вручную в коробку передач залезть, для замены передаточного числа.
> Лигика. Зачем вам ремни если вы только и делаете, что их отстегиваете, что бы вручную в коробку передач залезть, для замены передаточного числа.Ну так нет еще нормальной коробки.
Зато простое открытие двери не отрезает водителю ноги.Мне не нравятся аналогии с автомобилями, тк я езжу на метро.
Давайте лучше сравнивать с унитазами?
Ну так вот - унитаз локализует овно в квартире.
Как и unsafe в коде.
Ага. И периодически берет хозяин берет засучивает рукава и пригрошнями таскает его на улицу в туалет типа сортир.
Всякое бывает.
Но оно же не размазано равномерным слоем по полу, стенам и потолку?
Как было бы с СИ, где весь код unsafe.
Если на метро ездишь, почему ассоциация с унитазами?
> Если на метро ездишь, почему ассоциация с унитазами?Потому что унитаз есть в квартире любого человека.
А машина не у каждого.
И я без понятия что там у нее внутри, когда мне начинают заливать про коробки.
Тогда бери Java, JavaScript, Python, ну и т. д. и т. п. они то же не в курсе, как там и что внутри работает. И, в отличии от rust, им и не надо.
> Зачем вам ремни если вы только и делаете, что их отстегиваетеЛожная аналогия. Процент ансейф кода в ядре сильно меньше 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 ошибок, это несерьезно даже, но посмотрите на Раст - там целая одна, это же позор! Куда попгроммисты глядели!
Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен, сели в лужу. Не в первый раз уже причем.
> Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен,Да, он крут и безопасен в рамках гарантий которые он дает.
> сели в лужу.
Только в фанатазиях хейтеров.
> Суть новости в том, что любители Раста, которые кричали, что он крут и безопасен, сели в лужуЕсли одна растовая 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 - про это собственно новость.
И да - ссылку на лично вами написанный код пожалуйста, потом продолжим.
Было бы интересно заценить цифру отношения количества 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 в СИ мало кого волнуют.> Для системного программирования нет ничего лучше чистого Си.
По мнению кого?
Вон разработчики ядра решили что это не так.
У вас есть более высокии компетенции?
вот и миллионы индусов так говорят, пуляя новые ежемесячные апдейты на винду
> Закрытие уязвимостей обычнная работаКак, собственно, и их создание...
> напрямую работающих с указателями на предыдущий и следующий элементы спискаЭлементарный список не осилили. Какая же жесть должна быть в структурах посложнее.
так все опытные пограмисты новый язык уже где-то с середины книжки изучать начинают, пропуская вводую воду
Это язык в котором элементарный список без 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 не существует.Так вот, какие есть реалистичные предложения чтобы избавиться от части ошибок?
Хахаха, а ведь смешно облажались 😂
Радует только что в ансефе, а то совсем неудобно бы было.Впрочем, за свои действия нужно отвечать.
Готов принять лучи ненависти как топящий за раст.
> Хахаха, а ведь смешно облажалисьТы вот про этих? Настолько смешно, что уже даже не расписывают в новости, что опять накосолапили Сишники.
> вчера были опубликованы сведения о 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"Ясно. Вы расписываетесь в полном отсутствии у вас опыта программирования и соответствующих знаний. А значит ценность вашего мнения стремится к нулю.
> Ясно. Вы расписываетесь в полном отсутствии у вас опыта программирования и соответствующих знаний.Пф, логику вам кажется в школе не преподавали.
Вы случайно не на С/С++ пишете?> А значит ценность вашего мнения стремится к нулю.
Сказал человек не осиливший даже парсера.
>> Ясно. Вы расписываетесь в полном отсутствии у вас опыта программирования и соответствующих знаний.
> Пф, логику вам кажется в школе не преподавали.
> Вы случайно не на С/С++ пишете?
>> А значит ценность вашего мнения стремится к нулю.
> Сказал человек не осиливший даже парсера.Да-да-да...
>> Сказал человек не осиливший даже парсера.
> Да-да-да...Вижу что мы пришли к единому мнению.
За сим откланяюсь)
> За сим откланяюсь)Ну наконец то.
> А не в том, что кто-то нанимает людей с низкой квалификацией,
> сам никого не обучает и условия труда при этом как на галере.
> условия труда при этом как на галере.Что??? Это у гугла условия труда как на галере?!
Вы посмотрите какие у них условия труда и зарплаты!
Не пишите бред про то, что не знаете.Ну и про квалификацию вы тоже не правы. Если так рассуждать - то в ядре вообще нет квалифицированных разработчиков.
> Что??? Это у гугла условия труда как на галере?!
> Вы посмотрите какие у них условия труда и зарплаты!
> Не пишите бред про то, что не знаете.А что ж они тогда уязвимости втыкают?))
> Ну и про квалификацию вы тоже не правы.
Вопрос тот же.
> А что ж они тогда уязвимости втыкают?))Просто потому уязвимости не связаны с условиями работы.
А все ограничено физическими лимитами человека на внимательность.
Что в теории можно чуть-чуть подтянуть тренировками, но все равно найдется кодовая база с размером где любой человек не уследит.Просто джун запутается в 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
примерная иллюстрация ситуации: https://i.ibb.co/FkvFWv95/image.png
какой к чертям binder? есть posix ipc
Гугловцы пилят себе для андроида. Вернее переписывают то что используют сейчас
Это безопасное CVE, я ж правильно понимаю?
> Это безопасное CVE, я ж правильно понимаю?Более менее.
Упало и слава богу.
Нашли, пофиксили.Страшное это RCE.
то чувство, когда язык купил, а программировать не купил
Если бы это было бы написано на раст то тогда было бы безопасно