Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 58
In Rust we trust
Hurd это проект-анекдот, он может быть на чем угодно, всем плевать.
@moderator нарушение правил сайта
В моем комментарии был оттенок иронии и отсылка к фразе
"In God we trust"
Я люблю Rust, но далек от идеи, что это серебряная пуля.
зато появятся другие совершенно новые ошибки
как по мне лучше вылизанное решение которое точно проверили везде (баги исправляются если про них говорить, а не игнорировать)
а то это приведет к классике "у нас работает, проблема на вашей стороне"
Можете привести статистику с разбивкой: ошибки которые не устраняются при переходе c->rust / ошибки, которые устраняются / ошибки, которые привносятся?
я могу привести статистику как часто нужно вносить изменения с момента выпуска продукта для фиксов и до того момента когда частота правок практически сходит на нет
я именно про это и говорю - менять стабильно работающее что проверено уже миллиардами пользователями и годами использования, на "улучшенное новое" что должно делать то же самое
Статья:
никто не планирует переписывать всё ядро. Язык предлагают внедрять постепенно — прежде всего в новых драйверах и подсистемах.
Комментарий:
я именно про это и говорю - менять стабильно работающее что проверено уже миллиардами пользователями и годами использования, на "улучшенное новое"
Есть на хабре статья (https://habr.com/ru/news/1027834/) про попытку переписывания системных утилит в Linux с чистого Си на Rust. Компания по результатам переписывания заказала отчёт по уязвимостям. Результат:
В Rust версии идентифицировано 113 ошибок. (сарказм: Это ведь именно то, что вы хотели узнать?)
в оригинале: Across both rounds, 113 (73+40) issues of varying severity were identified. All findings were coordinated and reported upstream. Ссылка: https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773
в переводной статье: Компания Canonical опубликовала предварительные итоги независимого аудита безопасности инструментария uutils coreutils (Rust Coreutils), написанного на языке Rust и частично применяемого в Ubuntu вместо пакета GNU Coreutils. Аудит проекта выполняла компания Zellic, имеющая большой опыт по анализу уязвимостей в проектах на языке Rust. В ходе проверки специалистами было выявлено 113 проблем с безопасностью. Ссылка: https://habr.com/ru/news/1027834/
---
Прим.:
Чтобы не раздувать холивар, сразу скажу, что эти ошибки не связаны с памятью и её освобождением.
По настроению статьи получается такой конфуз:
Когда писали на Си, то было много всяких ошибок: и с памятью и с синхронизацией и много другого. И это всё годами полировали.
Когда попытались всё переписать на Rust, получилось, что с памятью-то проблем нет, но всё другое - осталось. А когда переписывали, то на очень много тонкостей забили - видимо, понадеялись, что компилятор всё равно ошибки отловит. Видимо, не отловил.
Текущий результат:
возвращены утилиты cp, mv и rm из набора GNU Coreutils
uutils coreutils возможно не хватает именно "проверки миллиардами пользователями и годами использования"? Ну так это временно.
И это всё годами полировали.
Толку-то от полировки годами, если в gnu coreutils в прошлом месяце починили повреждение памяти в... внимание... барабанная дробь... pwd.
'pwd' on ancient systems will no longer overflow a buffer when operating in deep paths longer than twice the system PATH_MAX. [bug introduced in coreutils-9.6]
Баг случился в 9.6 (март 2024), в 9.11 (апрель 2026) исправили.
2 года технически, конечно, попадает под "годами", но как-то уже не так страшно выглядит. Да и дальнейшее описание чуть уменьшает критичности.
Я к тому, что вылизанность годами, тулинг, обширная база пользователей не мешают ошибкам с памятью появляться снова и снова, даже в таких простых утилитах как pwd.
Да нет, как раз наоборот страшно выглядит: использование небезопасныого инструментария разработки приводит к тому, что даже в зрелом критическом софте возникают уязвимости. Т.е. даже если совсем-совсем идеально вылизать софтину, всё равно нельзя ни на миг расслабиться и почивать на лаврах, потому что, казалось, безобидные доработки могут породить уязвимость из-за того, что слишком просто "выстрелить себе в ногу"...
Так ошибки с памятью это самый мерзкий класс ошибок, потому что они стреляют максимально стохастически и их плохо видят даже самые продвинутые санитайзеры.
А вот логические баги таки рано или поздно вычистят.
Извините за минус, промазал по плюсу.
Если ему так хочется Linux на Rust - он может контрибутить в Asterinas.
Почему-то многие любители Rust, предпочитают не замечать этот проект, но тащить свое видение в уже устоявшуюся систему
Чем сильно смахивают на веганов и прочих активистов(
Если раст хорош - Asterinas выстрелит круче линукса, если нет - зачем переписывать на раст?
Полноте, при чём тут веганство! Сколько человеко-тысячелетий вложено в Линукс? Разве не очевидно, что шансов привлечь хоть сколько-нибудь сравнимое количество ресурсов у Asterinas нет?
Его предполагаемое преимущество в безопасности (предположим даже, что оно будет абсолютным, т.е. полное отсутствие уязвимостей - чего в реальности, конечно, достичь не удастся) - слишком нишевый фактор, недостаточный для того, чтобы "выстрелить" по сравнению с проектом, над которым работают на многие порядки больше людей. В Линуксе не настолько плохо с безопасностью. Нужны более весомые преимущества.
Поэтому естественно, что хочется сохранить все наработки и структуры, и улучшать ситуацию в существующем проекте. Прозрачным для пользоватей образом - т.е. им не надо разбираться в каких-то там новых ОС, просто у них то, чем они пользуются, станет лучше.
По крайней мере, я вижу так.
как по мне нейронки как раз таки лучшее для линукса, потому как они позволяют окончательно вылизать уже старые поверенные инструменты, добившись абсолютной стабильности
а переписывание на "безопасный язык" это всегда путь создания нового, то есть статистику использования и отлов краевых условий нужно начинать по новой, чему будут очень "благодарны" пользователи
старые поверенные инструменты, добившись абсолютной стабильности
Торвальц очень громко смеется с этих слов, приговаривая: “ipchains, iptables, netfilter, yep, it’s time to change it again”
Окончательное вылизывание кода просто позволит выйти на уровень насыщения количества неустранимых ошибок, количество которых зависит от используемой технологии/языка. И то это если функционал не добавляется/убавляется, компилятор не меняется и код идеально изолирован по инвариантам от зависимостей .
Есть подозрение, что у Rust это насыщение происходит быстрее, так ещё и уровень количества неустранимых ошибок ниже чем в С/С++. Это конечно можно будет подтвердить только со временем, но по крайне мере нет доводов для противоположного утверждения.
в Расте можно консервировано кодить начиная с 0 крейтов, скорее всего разговор про это, когда есть крейт, а нужен функционал с нуля, понятно что написание с нуля приемлемее, при тех возможностях Раста, проще писать на Расте действительно, просто писать нужно консервировано наверно.
хотя какая инфраструктура в Линуксе я не знаю на Расте.
сделайте уже хабр2, где будут существовать баны за иишный мусор вместо статей
Небольшая зависть грызет меня, как программиста на плюсах. И интерес: а сколько бы ошибок смогли избежать/добавили новых, если бы переписывали на современные плюсы?
Но пока жив Линус таких экспериментов боюсь не увидим.
Там же си в ядре, а не плюсы. А в даже самых современных плюсах нет кнопки отключить legacy
Очень большого количества проблем можно было бы избежать если бы компиляторы (что C что C++) явно бы жаловались на UB в коде. Вспоминая размер C++ стандарта (в страницах), я не уверен, существует ли в мире человек, который держит в голове все его утверждения. И с каждым новым стандартом ситуация становится все хуже и хуже...
Количество false-positive будет нереально большим, зачем это нужно? Вот пример, у тебя есть указатель на структуру, ты его разыменовываешь для каких-нибудь целей, а потом ниже по коду вызываешь другую функцию, в которой есть проверка на NULL. Компилятор инлайнит вторую функцию, видит проверку на NULL после разыменовывания, и зная про UB может эту проверку выкинуть. Но на что тут жаловаться и главное зачем?
Проблема в том что количество информации которую человек может держать в голове ограничено (ну или может это только я такой), и чем больше "особых случаев" существует, тем больше вероятность забыть про какие-то из них. Лично я бы предпочел возле каждого UB, который я проконтролировал, поставить лишнюю #pragma чем упустить его из виду. Это, кстати, сильно помогло бы с последующим восприятием кода.
Ну в этом направлении и идёт стандарт, разрабатывая safety politics. Можно будет четко сказать: в этом коде не должно быть никаких уб.
Ты мог взять указатель на переменную на стеке и передать в функцию, проверяющую указатель на NULL. В каком месте и зачем писать прагму? Что делать, когда прагма устареет, а ты забудешь её обновить?
Проверка указателя гарантированно не являющегося NULL на == NULL является UB?
Разыменование NULL является UB, поэтому увидев проверку на NULL после разыменования компилятор вправе выкинуть проверку.
Подскажите какой пункт стандарта это регламентирует?
6.5.3.2 If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
Плюс сноска: Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer...
в случае взятия адреса автоматической переменной разве где-то появляется "invalid value"? Про dereferencing в целом не возражаю, только при сравнении с NULL нет же dereferencing?
Сравнение с NULL выкидывается не потому что в нём UB, а потому что указатель не NULL, иначе бы предыдущее разыменование приводило к UB. Поскольку в программе UB не может использоваться, значит условие можно выкинуть.
Допустим в случае автоматической переменной компилятор имеет право выкинуть проверку (и то, если взяли указатель на автоматическую переменную и провели некоторые операции уже через указатель), но как только в коде появляется указатель на кучу передающийся в ту же самую функцию, компилятор уже не имеет права выполнять такую оптимизацию?
Если мы успели разыменовать указатель, и компилятор это увидел, он автоматически считает, что указатель не NULL, а значит проверка лишняя и её можно выкинуть.
"серебряной пули" не существует, и боюсь никогда не будет существовать...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Грег Кроа-Хартман: Rust спасет Linux от ошибок C