|
2.11, Аноним (11), 11:50, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Как я слышал, это от того, что ядро не разрабатывалось поддерживать такие вещи, и пихают невпиху3мое. А на модернизацию уйдёт ещё не одно десятилетие.
|
|
2.18, Аноним (18), 12:15, 01/04/2024 [^] [^^] [^^^] [ответить]
| –5 +/– |
> use-after-free
Дело скорее в языке, чем в самом io_uring (но надо признать, что автор эпично прошел по всем граблям сишечки).
|
|
|
|
4.25, Аноним (-), 12:44, 01/04/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
К чему твой висер типа "а у вас негров линчуют"?
Тред для растохейта на две тамы выше, дружок-пирожок.
У нас тут тема про то, что очередной погромист, любитель дыряшек, выдавил из себя такой код, что RCE в ядре была почти год.
И спасибо гуглу и его программистам, что они делают опенсорс лучше, а то тыщящи глаз как-то ничига не видят
|
|
|
5.54, Стив Балмер (?), 14:59, 01/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
так гугл как и мягкие это часть тысячеглаза, ты что не знал ? у них же куча продуктов на линь завязана, вот и стараются
|
|
5.55, Аноним (55), 15:06, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Тот же гугл не стал завозить Rust в Chrome, а решил свои проблемы с безопасностью памяти активным использованием санитайзеров включая MiraclePtr. Так что да, они делают опенсорс лучше.
|
|
|
6.68, Анонин (-), 15:54, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Тот же гугл не стал завозить Rust в Chrome
Точно не стал?
А то тут chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/rust.md#Rust-in-Chromium какие-то чуваки пишут:
"The Rust toolchain is enabled for and supports all platforms and development environments that are supported by the Chromium project. The first milestone to include full production-ready support was M119.
Rust is approved by Chrome ATLs for production use in certain third-party scenarios."
MiraclePtr себя не оправдал. Там улучшение ~57% при значительном потреблении ресурсов.
https://www.opennet.ru/opennews/art.shtml?num=60482
|
|
|
|
4.41, Аноним (18), 14:10, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Эпичный тред, в котором это пытаются заставить работать - https://github.com/Speykious/cve-rs/issues/4
Если для случайного выстрела в ногу, как в сишечке, нужен консилиум из нескольких программистов и несколько дней упорных попыток выйти за границы буфера - то это эпик фейл растохейтров.
|
|
4.45, Анонин (-), 14:24, 01/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ой, да ладно вам гнать на этот проект.
Он и аналогичные очень полезны! Благодаря им можно найти в расте soundness и исправить.
Потому что бездумно верить что багов нет - просто преступление.
Так что пусть чуваки развлекаются разными извращениями и в итоге делают раст еще лучше и надежнее.
|
|
|
|
2.22, Аноним (22), 12:34, 01/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Мне кажется система io_ring немного переусложнена там слишком много флагов, опций и режимов. Им нужно было начинать как-то попроще с минимум опций, а когда уже точно протестировано хорошо добавлять свои опции понемногу. Ну и сама конструкция с shared memory и кольцевыми буферами в ней не совсем уж простая в реализации.
|
|
|
3.57, Аноним (-), 15:22, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Не, не сработает.
Сразу начнется вой и нытье, что 'именно это флажок мне нужен', 'добавьте немедленно', 'работало, а вы все сломали', 'вы мне обязаны, 'я вашим ио-рингом пользуюсь'
Уже такое проходили с вейландом, когда с нуля начали создавать и реализовывать протоколы, так фанаты иксов ноют до сих пор.
|
|
|
2.65, Аноним (65), 15:42, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
По той же причине, что и в BPF, nftables. Не отловили ещё всех багов.
|
|
|
1.4, Аноним (4), 11:28, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Автора этого поделия давно пора взять на карандаш: не первая его уязвимость и что-то мне подсказывает, что не последняя.
|
|
|
2.30, Аноним (22), 13:10, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
В любом случае если его правильно реализовать это выходит самый эфиктивный способ i/o общения с ядром.
|
|
|
1.5, Аноним (11), 11:29, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Наверное, имеет смысл отключать сабж, вроде нигде кроме qemu и не используется (хотя ускорение обещают приятное в теории). Лично я давно отключил -- если я не использую, никакого смысла держать этот бэкдор ядре. Ну а кто там дистрибутивные ядра со всеми бэкдорами использует, тем только страдать.
|
|
|
2.7, Аноним (11), 11:36, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Правда, в libuv собирались добавить, и вот это поделие ускорить бы неплохо.
|
|
|
1.6, Аноним (-), 11:36, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Сначала подумал, что это шутка, ведь сегодня День Дурака.
А потом решил, это же use-after-free и получение рута, и с таким не шутят)
В общем классическая уязвимость "позволяющая непривилегированному пользователю получить права root в системе" да еще и с рабочим эксплойтом.
Хорошо, что это совсем-словсем не связанно с используемым языком, и возможностями по отстрела ног которые он дает.
|
|
|
2.19, Аноним (19), 12:17, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Да господи, язык тот тут причем?
Если программист не хочет или не может банально обнулить указатель после освобождения памяти, то увы, вина того, кто пишет
|
|
|
3.23, Аноним (-), 12:35, 01/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Хм, а я что сказал что "виноват язык"?
Понятно что програмер если захочет, то может сделать и один free, и два, и десять.
А потом попробовать обратиться к мертвому объекту.
Но представь у тебя есть две дороги, одна двухполосная без отбойника, а другая такая же но с отбойником. Как думаешь, где плохих аварий будет больше?
|
|
3.26, Аноним (26), 12:49, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Да господи, язык тот тут причем?
При том, что он не должен не должен пропускать подобные банальные штуки.
Если язык не может, значит нужно использовать чекеры, санитайзеры и прочие утилиты для обнаружения детских ошибок.
Если ни язык, ни экосистема этого языка не позволяют создать 100% защиту от подобных ошибок, значит виноват язык.
Здесь часто говорят, что "проблем нет, надо просто использовать простой советский...", но что-то в больших проектах никак не найдёт способ избавиться от детских болезней. Вывод очевиден - это невозможно, и виной - язык.
|
|
|
4.33, ИмяХ (ok), 13:18, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
>>значит нужно использовать чекеры, санитайзеры и прочие утилиты для обнаружения детских ошибок
Но почему-то никто этого не сделал перед тем, как принять код в ядро. Ни комитет, который принимает патчи, сам Линус, ни мейнтейнеры, ничего не сделали, чтобы предотвратить это. Либо делали, но намерено скрывали, чтобы продать информацию троянописателям.
|
|
|
5.35, Аноним (-), 13:32, 01/04/2024 [^] [^^] [^^^] [ответить] | +/– |
Давай воспользуемся бритвой Хэнлона и попытаемся не приписывать злому умыслу то... большой текст свёрнут, показать |
|
5.60, Аноним (60), 15:27, 01/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Сам Линус как был замшалым финским студентом с версией 0.1, так и остался им на всю жизнь. Отсюда и все беды Linux. В академических осях инновации более осмысленные. Как следствие, проблемы намноооого реже. Линуса от управления разработкой ядра надо давно смещать. Сейчас в ядро тянется все подряд, а Линус, как собачка на торпеде, одобрительно на всё.
|
|
|
4.43, Витюшка (?), 14:16, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
В ядре часто код который в main попадает тупо банально даже не компилируется!!! На это раз жаловался сам Линус. Так что до стадии "виновата С дыряшка" там просто не дошли.
|
|
|
5.46, Анонин (-), 14:27, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> в main попадает тупо банально даже не компилируется
Серьезно?
А можно ссылки на PR или обсуждения?
Потому что это... это даже не неуважение к участникам, а какая-то профнепригодность какая-то.
У нас бы такого разраба бы просто уволили, если бы не исправился.
PS: как вообще можно залить некомпилируемый код? Его же CI не пропустит.
|
|
|
6.61, User (??), 15:27, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> PS: как вообще можно залить некомпилируемый код? Его же CI не пропустит.
Хе-хе-хе. Какой-такой си-ай хен-тай? Мы такого не знай - вон, оно в почту пролезай - фигли еще надо?!
|
|
|
|
|
3.27, Аноним (27), 12:53, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
В нормальных же языках такое в принципе нельзя сделать. Памятью там управляет не программист, а сборщик мусора.
|
|
|
|
5.48, Аноним (27), 14:38, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ответ был на фразу "да причем здесь языки вообще". Что стоит использовать или нет в ядре - это существенный вопрос конечно, но другой.
|
|
|
|
|
4.69, Аноним (19), 16:08, 01/04/2024 [^] [^^] [^^^] [ответить] | +/– |
Ну тогда asm volatile заинлайнить, где тупо xor делается, такое по идее не должн... большой текст свёрнут, показать |
|
|
3.70, fidoman (ok), 16:14, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Угу, а также найти все прочие указатели на эту область памяти, и тоже обнулить.
И ядру сказать, вот я передавал указатель при вызове асинхронной функции, его тоже обнули.
Если бы всё так просто решалось...
|
|
|
|
1.8, Аноним (8), 11:38, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Какого лешего io_uring можно отключить только переконпеляцией? Почему не сделают аргумент командной строки, чтоб можно было продолжать использовать дистрибутивные ядра, но без io_uring?
|
|
1.29, Аноним (29), 12:55, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что такое этот io_uring и можно ли его отключить?
И да, кто-то тестил у себя этот эксплоит? Что он делает с системой?
|
|
|
2.64, Аноним (60), 15:35, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Так уже есть почти готовый Hurd или Plan9. Пора кому-то авторитетному закопать у себя Linux. Глядишь и другие потянутся к новому.
|
|
|
1.49, Golangdev (?), 14:38, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> В настоящее время публично доступен работающий эксплоит, а также подробно описана вторая техника эксплуатации уязвимости.
вот это я понимаю, предоставили пруф.
а не то как другие - типа "-ааа, уязвимость, ааа, паника, срочно покупайте наш ссаный антивирус, но пруфа мы не предоставим"
|
|
1.52, Аноним (52), 14:49, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Астрологи продлили месяц уязвимостей. Продолжительность месяца уязвимостей теперь неизвестна.
|
|
|
2.53, Аноним (-), 14:52, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Астрологи продлили месяц уязвимостей.
> Продолжительность месяца уязвимостей теперь неизвестна.
А не подскажите когда он начался?
Потому что по ощущения лет 7-8 назад.
|
|
|
3.59, Аноним (55), 15:26, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Так это стратегия пиара раста такая. Своих достоинств у языка мало, внедрение идет с трудом, вот и приходится очернять другие языки, откапывая или придумывая всякий негатив.
|
|
|
4.63, Аноним (-), 15:32, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> откапывая или придумывая всякий негатив.
Ты хочешь сказать "лучше бы исследовали умолчали о проблеме?"))
Или это просто растовики прокрались и подбросили кучу прямо в штаны разработчиков io_uring?
Какое чудовищное коварство!
Хотя погоди-ка.., сишные дырени находили еще в той зловонной куче кода именуемой ХОрг, причем их там положили в далеком 1988 году, когда раста еще не было даже в проекте, а его создатель наверное ходил в школу...
Точно! Это были путешественники во времени.
На что они только не пойдут ради очернения дыряшки!
|
|
|
|
2.62, Аноним (-), 15:27, 01/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Месяц уязвимостей вышел за границы выделенного буфера фиксированной длины.
Он продлится ровно столько, пока пограммистоы не научатся работать с памятью.
Т.е, возможно, никогда.
|
|
|
1.67, Аноним (67), 15:45, 01/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Проблема проявляется начиная с выпуска ядра Linux 6.4
Новые выпуски ядра должны решать проблемы, а не создавать их
|
|
|