CVE-2025-68260: Первая уязвимость в коде Linux на Rust

Доступ к объектам в памяти - это тоже thread-safety.

А какие есть проблемы с доступом, кроме гонок?

Дедлоки, например.

Дедлоки, например

Дедлоки это результат гонок, дядя.

Рад что тебе ясно, а многим не ясно, потому что картина мира несколько сложнее. Возьмём то же экспертное сообщество, например, Торвальдс читает код C быстро и глубоко осознанно, а раст нет, о чём он сам говорил. И что новые разрабы напишут, если экспертизы нет? Фуфло они напишут.

Это логическая ошибка поверх вполне работающих примитивов. Если у тебя есть thread-safety, это не гарантирует отсутствие дедлоков. Дядя.

что новые разрабы напишут

Предлагаешь новых разрабов не пускать к ядру? Старые помрут от старости, и хрен с ним с ядром?

Это пустое словоблудие. Расту уже 19 лет, со всеми вытекающими. Экспертиза накоплена.

Предлагаешь новых разрабов не пускать к ядру? Старые помрут от старости, и хрен с ним с ядром?

Я предлагаю продолжать писать на С, тогда будет преемственность и экспртиза кода.

Экспертиза накоплена.

У разработчиков ядра нет.

Зато по сям накоплена, а растом занимаются те же люди, что и сями.

Линус Торвальдс, Алан Кокс, Грег Кроа-Хартман, Инго Молнар, Эндрю Мортон, Ларри Фингер, кто из из них занимается растом?

Счекаути репозиторий и погрепай. А еще можешь попробовать поискать коммитеров раста, и сделать пересечение с их же коммитами на сях. Дерзай.

Бремя доказательства на утверждающем, так что погрепай, поищи, отсортируй и выкладывай, иначе пустословие.

Вот и доказывай, мы сейчас разбираем именно твои голословные выдумки. А то как чушь молоть языком - так это ты горазд, а как я с тебя потребовал доказательств - начал скулить про «ряяя доказательства будут, точно будут, но потом».

Not U здесь не работает, молодой человек :)

Слив засчитан, клоун.

Бывай, балабол :)

балабол

Ну-ну, фантазёр. Спокойнее будь, а то еще сердечко екнет. Мы с тобой уже выяснили, что балабол здесь именно ты.

Большой опыт позволят предвидеть дальнейшее развитие событий. Не всем доступно, понимаю.

Спокойнее будь, а то еще сердечко екнет

Ой, у балаболки попочка подгорела :)

Бывай, балабол :)

Ой, у балаболки попочка подгорела :)

Ты попрощался и ушел, клоун. Будь хотя бы последователен, раз уж не способен отвечать за свои слова :3

Не попрощался, а отправил тебя в известном направлении, но ты продолжаешь гореть и вопить как потерпевший, отвечаю чтоб угомонить немного, а то стул сожжёшь :)

Не попрощался, а отправил тебя в известном направлении

не способен отвечать за свои слова

ЧТД.

… человек может ошибиться из-за человеческого фактора.

И должен отвечать за свои ошибки, а не: «Это не я, это всё компилядор».

Как одно мешает другому?

Человек должен выдумывать алгоритм. А его имплементацию на конкретной вычислительной платформе должна полностью автоматически генерировать машина. Мы к этому ещё придём.

Зачем далеко ходить? Человек выдумывает алгоритм. Говорит машине на понятном ей языке как его реализовать и алле оп… Ничего не напоминает? К этому уже давно пришли. Просто некоторые человеки не очень хорошо умеют общаться с машиной.

К этому уже давно пришли.

Ещё нет. Увы. Сейчас разработчик вынужден уделять слишком много внимания именно имплементации, а не самому алгоритму. Но всё идёт к тому, что на машину свалят всю рутинную работу.

Как одно мешает другому?

А я говорил, что что-то чему-то мешает? Да, люди ошибаются. Но профессионалы ошибаются значительно реже, чем дилетанты.

Есть определенная разница между формальном и естественными языками. Если ты записываешь алгоритм на формальном языке, исключающем двойное толкование, то будешь получать детерминированный результат.

В расте нет вообще никакой магии, просто определенные правила того, как ты можешь обращаться с объектами в памяти. Ты следуешь этим правилам, и компилятор генерит тебе код для предусмотренных правилами условий. Всё остальное просто не скомпилируется. Тебя же не смущает, когда сишный компилятор ругается на синтаксические ошибки или несоответствие типов? Вот тут то же самое, только с более глубоким анализом.

А если тебе надо что-то за пределами предложенных правил, то unsafe к твоим услугам. Это буквально как сишка, можешь хоть гланды через одно место достать, только аккуратно. При этом надо понимать, что раст не защищает от логических ошибок (ни один язык не защищает) и от ошибок в unsafe. Но от ошибок с памятью вне unsafe, из которых состоят почти все CVE, он защищает.

А профессионалы, вооружённые инструментами, снижающими вероятность ошибки, ошибаются реже, чем просто профессионалы.

А профессионалы, вооружённые инструментами, снижающими вероятность ошибки, ошибаются реже, чем просто профессионалы.

Вот как-то сложно спорить с очевидным.

А дилетантам не помогут никакие инструменты.

не обязательно. Они привыкают к этим инструментам, расслабляются и срабатывает человеческий фактор

Ты уже отказался от использования компиляторов и перешел обратно на хекскоды? Не время расслаблятсья.

не обязательно

Ну вот, уже торгуешься. Обоснуй, почему это применимо к ситуации с растом?

привыкают к этим инструментам, расслабляются

А к памяти по прежнему не могут обратиться некорректно, т.к. инструмент не позволяет.

расслабляются

Ну да, все знают, что профессионалы способны напрягать мозги на все сто всё своё рабочее время и не выгорать от этого за полгода.

Обоснуй, почему это применимо к ситуации с растом?

Потому что привыкнув писать safe код человек с боольшей вероятностью ошибётся в unsafe блоке. Это человеческий фактор.
Ещё в rust есть ещё cargo-фактор, когда упростив упровления зависимостями и создав удобную экосистему людям развязывают руки и она остановится неудобной и приносит больше проблем, чем пользы

А к памяти по прежнему не могут обратиться некорректно, т.к. инструмент не позволяет.

unsafe же

Ну да, все знают, что профессионалы способны напрягать мозги на все сто всё своё рабочее время и не выгорать от этого за полгода.

да, это тоже важный фактор. Но присутствие удобного инструмента не избавит от выгорания. Очевидно, что мозг надо разгружать от рутинного управления памятью. Но для этого достаточно сделать удобный механизм управления лайфтаймами.
А универсально удобного механизма под все случаи нет.
Где-то удобны пулы, где-то перемещение, где-то просто хранение на стеке, где-то shared_ptr, а где-то и целый gc нужен
Ну и почти каждый раз когда мы выбираем удобство - мы жертвуем какими-то ресрусами. Всё программирование это балланс на грани между ресурсами потребления программы и ресурсами усилий программиста. Но иногда при неправильном выборе теряются оба ресурса, как и если уйти в крайность. rust - это одна из таких крайностей, хотя там можно найти эффективное подмножество. Но представляется он почему-то как панацея от всех проблем, настолько что даже смешать разные, несовместимые между собой языки в ядре, бжлад, операционной системой ради него посчитали допустимым хотя это полнейший nonsense. Включение c++ (без stl) в ядро было бы незаметным изменением по сравнению с rust, но этого не захотели ни какой ценой (пусть и существуют out-of-tree модули на c++ и нормально работают, зато rust тащат любой ценой. И ценой неудобств для мейнтейнеров, и ценой недоступности для rust кучи интерфейсов

Потому что привыкнув писать safe код человек с боольшей вероятностью ошибётся в unsafe блоке. Это человеческий фактор.

Поэтому давай выбросим вообще все проверки и будем херачить небезопасный код с сотнями CVE по ошибкам памяти. М-м-м, класс.

Мы к этому ещё придём.

Хорошо бы конечно, но функциональная парадигма как-то медленно набирает популярность среди людей. Надеюсь ИИ с этим поможет.

привыкнув писать safe код человек с боольшей вероятностью ошибётся в unsafe блоке

Обоснуй. unsafe код не похож на safe, привычка к одному не приводит к привычке к чему-то другому.

cargo-фактор

К ядру линукса не относится

Включение c++

Угу, ко всем UB в си, которые нужно постоянно держать в голове, добавить UB из цпп. Вот уж разгрузка так разгрузка.

Я предлагаю продолжать писать на С

Продолжай, разрешаю. А в этой новости-то ты что забыл?

Потому что наш декларативно мыслящий мозг ломают об колено первым же императивным языком программирования. Практически все изучают основы программирования и набирают свой первый самый ценный опыт в императивщине. А потом даже с банальным SQL возникают проблемы, потому что мышление уже сломано напрочь.

А в этой новости-то ты что забыл?

Решительно противодействую безумию, которое убьёт линукс.

Обоснуй. unsafe код не похож на safe

довольно похож. Да и дело тут скорее не в привычках к определённоиму поведению, а в привычках следить за работой с памятью

К ядру линукса не относится

но относится к подходу rust в целом. Хотел добавить что это не про ядро, но не стал

добавить UB из цпп

Да и добавлять ничего не придётся, если выкинуть stl - все ub там общие с сишкой

ну так всегда так и делали. У ядра ОС есть другие задачи помимо всяких там проверок

Ты код ядра давно читал?

вчера

Ты уже дурачишься.

Молодец. А теперь вспомни, что там полно самых разных проверок по памяти и пограничным условиям. Сложи два плюс два и осознай, что лучше, чтобы этим занималась машина, и прекрати нести ерунду.

Когда люди пишут код, они, вообще, склонны думать. И если их мозг будет освобожден от пердолинга с памятью, то они смогут загрузить больше контекста о более высокоуровневой логике.

В чем конкретно выражается твое противодействие, помимо нытья на лоре? Где можно посмотреть код, который ты пишешь?

Вообще «unsafe» в расте не совсем удачный термин, т.к. неточно отражает суть происходящего. Больше подошло бы что-то типа «unrestricted», типа можно делать то, что запрещено по умолчанию, но на свой страх и риск. Так было бы понятнее людям, незнакомым с языком, а то слово «unsafe» некоторых пугает.

в привычках следить за работой с памятью

unsafe нужен в пяти случаях: разыменовать сырой указатель, вызвать функцию с пометкой unsafe, работать с мутабельной статической переменной, имплементировать трейт с пометкой unsafe, работать с полями union. Компилятор по-прежнему будет работать с памятью за тебя, борроу чекер по-прежнему будет ругаться. Ты серьёзно считаешь, что человек написав впервые за месяц *ptr не заметит из-за привычки, что в этой строке происходит что-то особенное? К тому же, обращу внимание, блоки кода с unsafe обычно не превышают одной-двух строк, на которых нужно концентрировать внимание и в которых вообще-то довольно сложно затупить в доступе к памяти, только каким-нибудь максимально неочевидным способом, как например, в топике.

Вот знаете, идет какой то офтоп. Никто не обсуждает код и что там вообще происходит и как так получилось и что там накастылил Грег Кроа-Хартман. Идет просто срач. А вообще ситуация интересная: чтобы получить максимальную производительность, авторы осознано отбрасывают все safe методы и начинают на прямую управлять гуардами и памятью, на этом они получают прирост производительности, но ошибаются и получают повисший гуард, который может привести к deadlock. Грег решает эту проблему, и руинит производительность примерно в двое, из-за того что гуард сбрасывается на каждой итерации.