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

Это буквально оно. В древние времена тоже было очень много воя по поводу языков высокого (на тот момент) уровня примерно с той же аргументацией.

Опять не в ту лужу и не то сравниваешь…

Управление памятью по понятным паттернам - вещь, которая может быть сделана машиной без всякой недетерминированной эвристики.

вообще ни разу… (работа с прерываниями тому свидетель… база же…)

Ты точно программист, или просто теоретизируешь? Какое отношение линтеры имеют к производительности?

у меня такой же вопрос возникает к тебе… Как думаешь если литералов будет бОльше в связи с дополнительными проверками, то программа станет производительнее…???

Не оказалось.

Оказалось, собственно… (Ты б мысль озвучивал, а то дет.садом такой диалог попахивает)

коротко, если язык защищает от части гонок, то гонки имеют отношение к языку. Или нужно уловить какой-то тонкий, художественный смысл высказывания «гонки - не имеют отношения к языку», но этого я не осилил, уж извините. Для меня это звучит как просто попытка замылить тему и враньё.

Race condition — это не проблема языка. Это проблема взаимодействия потоков управления во времени.

Я просто на расте не пишу, но на Си - эти моменты программист контролировать может…

Опять не в ту лужу и не то сравниваешь…

Да нет, всё в порядке. Ты просто не подумал.

вообще ни разу… (работа с прерываниями тому свидетель… база же…)

Это частный случай, для которого существует unsafe. Для бизнес-логики, которая является подавляющим большинством написанного кода, работа с памятью легко автоматизируется.

у меня такой же вопрос возникает к тебе…

Мой гитхаб в профиле. Итак, еще раз: какое отношение линтеры имеют к производительности?

Оказалось, собственно…

Нет, не оказалось. Сбой в unsafe-блоке, а не в самом расте. Это логическая ошибка, от которой ни один язык на защищает.

Осталось ещё понять, что там такого связанного с оборудованием в этом связанном списке. Видимо, «список, связанный с оборудованием», который нельзя сделать не-ансейф, да? :)

если язык защищает от части гонок

Ты будешь продолжать настаивать на этой чуши и игнорировать пост, где мы с тобой выяснили, что официально растом это не заявляется?

Можешь разобраться в причинах того, зачем там существует unsafe. Разрешаю. Дерзай. Изучишь - расскажешь.

Ты это буквально комментируешь в новости про устранение дыры в безопасности ядра, LOL.

Я комментирую в новости про серебряную пулю rust, которая, на поверку, оказалась пулей из известной дурнопахнущей субстанции. Да и «знакомые с безопасностью» никаких дыр в ядре не патчат :)

Т.е. «мы можем, но неофициально и давайте пожалуйста тихо». А те, кто на Хабре про это трубит на весь мир - это лохи, которые палят контору? Мне это уже напоминает произведение «большая глина» или как там оно называлось - такое вот нагромождение художественных образов.

Я комментирую в новости про серебряную пулю rust

А разве кто-то кроме раст-хейтеров такую чушь нёс? Где?

Т.е. «мы можем, но неофициально и давайте пожалуйста тихо».

Ты принесешь цитату из официального англоязычного источника, а не из рандомной статьи на хабре, или мне считать твой слив засчитанным? Где это утвреждается на сайте раста? Бегом.

«guarantee memory-safety and thread-safety» , объясни мне, как thread safety ортогональна гонкам теперь. С каждой новой репликой - новый кусочек глины :)

Ладно, я ушёл. Разбирайтесь сами в вашем художественном творчестве.

А разве кто-то кроме раст-хейтеров такую чушь нёс? Где?

Нет никаких раст-хейтеров, есть компетентные программисты, пишущие на C и все остальные. Хейтеров не видел.

Ну может, но только головой. Предполагая, что доступ к некой структуре данных из одного потока должен произойти не раньше, чем эту структуру данных заполнит или изменит другой поток, можно как-то обвесить структуру атомарными счетчиками, мутексами и т.п. Я тоже на расте не пишу, но покопал что-то, так в unsafe-блоке раст от Си отличается только синтаксисом. А подходы — те же. Оба языка императивные, просто считай что в расте все ссылки обвешаны всякими умными Uniq-указателями по умолчанию.

thread-safety

Это широкое понятие, если ты не знал. Доступ к объектам в памяти - это тоже thread-safety.

Впрочем, конечно, ты не знал. Теперь можешь поискать на официальном сайте список того, от чего конкретно раст защищает, и прекратить уже пороть чушь.

Ну это плохо применимо для верификации отсутствия гонок. В логических моделях фактор времени плохо учитывается, если учитывается вообще.

С помощью логики разделения это делается, на https://iris-project.org/ полно работ на тему.
Растовая система типов похожа на игрушечную версию логики разделения. Простые случаи покрывает, но для случаев посложнее требуется ансейф.
https://arxiv.org/pdf/2403.15122 пользуется этим, кстати, требуя логику разделения только для верификации ансейф частей.

Кстати, для раста есть что-то похожее — https://frama-c.com/html/acsl.html

Creusot, Verifast.

Си приучает думать. Потому чел быстро заметил косяк. Раст отучает думать. Вот и серьезный косяк всплыл.

Я не растаман, и вряд ли им стану :) Я свой матрас травы уже выкурил. :)

Си приучает думать.

Думать это ж сложно очень. Полагаю раст создан для написания кода ИИ.

Вся суть руста.

Все правильно, в си у тебя все один большой unsafe блок, а тут ограниченные куски кода.

Да нет, всё в порядке. Ты просто не подумал.

Ты в факты умеешь или только мнениями оперируешь..?

Это частный случай, для которого существует unsafe. Для бизнес-логики, которая является подавляющим большинством написанного кода, работа с памятью легко автоматизируется.

Тех «частных случаев» сильно больше чем ты себе представляешь… И unsafe - это расписка в неспособности соответствовать своей же парадигме «безопасности»…

Мой гитхаб в профиле.

Глянул профиль, там чисто твоего: питон, да шелл с html, остальное форки, которые можно было б и самому осилить, не прибегая к помощи (если за скилловость говорить) - не впечатлило, но похвально, что есть…

Итак, еще раз: какое отношение линтеры имеют к производительности?

Тебе дан ответ, ты читать разучился…? С чем ты хочешь поспорить в моем ответе…? (особенно странно это в свете того, что у тебя же на гите есть вроде железки в проектах - или ты «пользоваться», но сам «не писать»/«не разбираться»?)

Нет, не оказалось. Сбой в unsafe-блоке, а не в самом расте. Это логическая ошибка, от которой ни один язык на защищает.

удобненько, unsafe виноват получается, а его растерам злые Си-шники видать заслали и заставили пользоваться, и, самое важное, unsafe - это не раст, так…?

Спасибо, интересно.

компетентные программисты, пишущие на C и все остальные

Классификатор мамкин. Борхес практически: «принадлежащих Императору, набальзамированных, молочных поросят…».

Си приучает думать.

Программировать на С тебе, я так понимаю, не доводилось?

А чего, на С можно быдлокодить не приходя в сознание, но результат немного предсказуем? И поэтому понадобился раст? Но тоже не оправдал ожидания. Что же делать? Ну не начать же думать в конце концов :)

не впечатлило, но похвально, что есть…

У тебя, что характерно, нет.

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

Да, можно. И именно поэтому Линус решил внедрять раст в ядре.

У тебя, что характерно, нет.

Потому что в основном проприетарщиной занимаюсь (закрытые репозитории и большинство мне не принадлежат, а сливать себе и открывать - это как-то неправильно, ибо я «продал» это как бы, да и есть интересные решения, которыми не хочу делиться с «незнайками и непонимайками» - пусть ИИ спрашивают…), а пару форков, которые я на посмотреть залил - вряд ли кому-то интересны… Очевидно же…

Да, можно. И именно поэтому Линус решил внедрять раст в ядре.

ИИ:

Решение о внедрении Rust в ядро Linux было принято при активном участии создателя Linux Линуса Торвальдса. После долгих обсуждений и первоначального сопротивления, Торвальдс признал преимущества Rust, особенно в части безопасности памяти, и подтвердил продолжение интеграции, что сделало его использование в ядре официальной частью разработки, а не просто экспериментом, несмотря на споры в сообществе. Ключевую роль также сыграл ведущий разработчик Грег Кроа-Хартман, который продвигал использование Rust для устранения типичных ошибок. 

Если ИИ опять не нафантазировал, то Торвальдс Согласился, его Убедили, есть даже предположение, что недавние события, связанные с увольнением российских разработчиков, и т.п. сыграли не малую роль… Торвальдс в свое время даже плюсы хейтил, если что… Также Торвальдсу «побарабану» будет линукс корпоративным/проприетарным или свободным, для него это просто интересный проект (если смотреть его выступления, то такое мнение складывается)

Ты в факты умеешь или только мнениями оперируешь..?

Факты были даны, ты их проигнорировал.

Тех «частных случаев» сильно больше чем ты себе представляешь

То, что их много, не отменяет того, что проблем с памятью еще больше.

остальное форки

Ты ж банально врешь, клоун :)

Тебе дан ответ, ты читать разучился…?

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

Всем вполне очевидно, кто из нас двоих не умеет читать.

удобненько, unsafe виноват получается

Виноват код внутри unsafe. Перечитывай выше то, что я писал о бизнес-логике другим юзерам.

Судя по тому, что ты путаешь линтеры с литералами - ты занимаешься прикладным магазиностроением на PHP.

Торвальдс Согласился, его Убедили, есть даже предположение

Что только шизофреники не придумают, лишь бы не признавать ряд простых фактов:

• Раст безопаснее Си по части работы с памятью.

• Старички-сишники потихоньку отъезжают на пенсию.

• Новые разрабы хотят радикально порешать старые проблемы ядра, и для этого нужен новый язык.

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

Если не вливать молодую кровь в проект - он постепенно загнется. Особенно когда всякая фуксия и прочая новоиспеченная номинально-свободная проприетарщина на подходе. Так что всё правильно сделал.

Еще и redox продолжает расти и развиваться

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

Факты были даны, ты их проигнорировал.

Факт пока один: ты сравнил абстрактное именование команд с переписыванием логики работы программы «на усмотрение машины»…

Ты ж банально врешь, клоун :)

У бати своего спроси, когда он из цирка тебя забирать будет, а по приходу глянь в репозитории «свои», там форк на форке, даже ридми не троганны руками,

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

хах, иди в подворотню сходи, там твои друзья пузырь открыли уже…

Всем вполне очевидно, кто из нас двоих не умеет читать.

Согласен.

Виноват код внутри unsafe. Перечитывай выше то, что я писал о бизнес-логике другим юзерам.

бизнес-логика не требует от тебя unsafe… Трезвей короче..

Более можешь не отвечать, ты ушел в игнор, не марай клаву, пузырь с корешами у тебя стынет…

линтер:

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

… работа должна быть переложена на него… компилятор в состоянии закрыть большую часть проблем…

Как бы верно, но немного спорно. Машина должна работать, а человек всё-таки должен думать.

Очевидно же…

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

Во-первых, не только; во-вторых, ты всё еще не ответил на вопрос - каким образом это влияет на производительность.

Да, можно. И именно поэтому Линус решил внедрять раст в ядре.

Так может проще на мороз тех кто так могут практикуют?

Машина хороша в выполнении дубовых алгоритмов. Вот и пусть работает над тем, где человек может ошибиться из-за человеческого фактора.

Машина должна работать, а человек всё-таки должен думать.

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

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

Да что вы говорите… Ощущаю безумие юношеского максимализма :)

Так некому будет линукс писать. На один этот обсуждаемый CVE пришлось 159 в сишном коде в тот же самый день.

Факт пока один: ты сравнил абстрактное именование команд с переписыванием логики работы программы «на усмотрение машины»…

И ты снова врёшь. Сравнение было буквально с путем развития компиляторов и интерпретаторов.

У бати своего спроси

Лол, клоун аппелирует к шуткам про батю/мамку. И врёт, к тому же. У меня, конечно, есть личные хейтеры, но они хотя бы набрасывают говно на мой существующий сишный код и патчи на ядро, ты же банально отрицаешь сам факт наличия кода, который висит буквально на первой странице.

хах, иди в подворотню сходи, там твои друзья пузырь открыли уже…

Кто пустил быдло на лор?

бизнес-логика не требует от тебя unsafe

Конечно, не требует. Я буквально это писал.

Трезвей короче

Ах, эти милые проекции.

Более можешь не отвечать, ты ушел в игнор

Бгг. Поймали на вранье, сгорел - спрятался за игнором. Эталонный клоун.

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

Организационные возражения, в данном контексте, значительно важнее технических. Новые разрабы на новом «хорошем» расте вам такое напишут, что старые разрабы с «плохим» С покажутся богами от программирования.

Где доказательства этой голословной чуши?

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

Ясно, никаких доказательств нет, есть только чувственные ощущения.