https://www.opennet.ru/openforum/vsluhforumID3/133278.html В интерфейсе асинхронного ввода/вывода io_uring, предоставляемом ядром Linux, выявлена уязвимость (CVE-2024-0582), позволяющая непривилегированному пользователю получить права root в системе. Для эксплуатации уязвимости достаточно обычного локального доступа к системе, без необходимости манипуляций с пространствами имён. В настоящее время публично доступен работающий эксплоит, а также подробно описана вторая техника эксплуатации уязвимости...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60891<br> https://www.opennet.ru/openforum/vsluhforumID3/133278.html#153 Wed, 03 Apr 2024 16:39:16 GMT &gt;[оверквотинг удален]<br>&gt; let global_structures = Mutex::new(GlobalStructures::new()); <br>&gt; Если твой обработчик сделал: <br>&gt; if let Ok(gs) = global_structures.lock() { <br>&gt; // то здесь у него есть эксклюзивный доступ <br>&gt; к этим структурам через gs <br>&gt; } <br>&gt; Подобный подход наверное не очень хорош, когда речь идёт о файловой системе, <br>&gt; но файловая система это лишь один из возможных примеров. А если <br>&gt; ты уже получив гарантии эксклюзивности доступа будешь использовать атомарный Arc, вместо <br>&gt; Rc, то тебе наплевать на производительность щтоле?<br><br>Подобный подход вообще не очень хорош, потому что все вызвавшие syscall приложения кроме одного дружно остановились в одном месте. О какой производительности говорить, когда мютекс вызвал планировщик и процессор принялся исполнять какие-то другие потоки? Сравнивать перезагнузку контекстов с каким-то счётчиком?<br><br>&gt;&gt; placement new не нужна куча.<br>&gt; А, ты хвастаться знаниями пришёл и докапываешься к словам, ожидая когда я <br>&gt; начну комплименты твоему интеллекту и по https://www.opennet.ru/openforum/vsluhforumID3/133278.html#152 Wed, 03 Apr 2024 15:46:58 GMT &gt;[оверквотинг удален]<br>&gt; в любой реализации кучи, которая отдельно следит за маппингом памяти, отдельно <br>&gt; за занятыми виртуальными адресами.<br>&gt; В данном частном случае, я отмечу, всё было сделано так, что в <br>&gt; момент, когда страницы надо было анмапить, было невозможно решить надо ли <br>&gt; анмапить или не надо, потому что владельцем этих страниц мог быть <br>&gt; юзерспейс, если он мапил, или кернелспейс, если мапил он.<br>&gt; То есть в ядре было понятно, что можно (и нужно) реклаймить виртуальную <br>&gt; память из-под буферов и помечать свободной, а вот что делать с <br>&gt; физической памятью уже было не ясно, потому что ключевая для принятия <br>&gt; решения информация была утеряна к тому моменту.<br><br>Вот эту последнюю проблему и решает RAII. Всё освобождается в одном месте - деструкторе (а что именно освобождается - это вообще дело десятое). Но может так оказаться, что всё это затруднительно завернуть в одну обёртку. Потому что архитектуру проектировали под язык Си и без расчёта на такое. То есть я веду вовсе не к тому, что плю https://www.opennet.ru/openforum/vsluhforumID3/133278.html#151 Wed, 03 Apr 2024 13:12:49 GMT &gt;&gt; Если первое, то там оно не решается при помощи shared_ptr. Там память<br>&gt;&gt; была освобождена, но не была отмаплена.<br>&gt; Значит решается другим частным случаем RAII, где освобождение всех ресурсов происходит в одной точке?<br><br>Это решается интеллектом, который должен остановиться и подумать, что речь идёт о двух уровнях динамической аллокации. Аллокация виртуальной памяти отдельно, аллокация физической памяти, чтобы пополнить виртуальую, тоже отдельно. Ты можешь видеть это в любой реализации кучи, которая отдельно следит за маппингом памяти, отдельно за занятыми виртуальными адресами.<br><br>В данном частном случае, я отмечу, всё было сделано так, что в момент, когда страницы надо было анмапить, было невозможно решить надо ли анмапить или не надо, потому что владельцем этих страниц мог быть юзерспейс, если он мапил, или кернелспейс, если мапил он.<br><br>То есть в ядре было понятно, что можно (и нужно) реклаймить виртуальную память из-под буферов и помечать свободной, а вот что делать с физической памятью уже было не яс https://www.opennet.ru/openforum/vsluhforumID3/133278.html#150 Wed, 03 Apr 2024 12:40:18 GMT &gt; Такие попытки как раз и будут. Приложение вызвало syscall, далее поток работает в ядре и лезет куда-то в структуры примонтированной ФС. Они общие для всех? Сколько ещё других приложений делают тот же syscall - неизвестно.<br><br>Представь себе ситуацию:<br><br>let global_structures = Mutex::new(GlobalStructures::new());<br><br>Если твой обработчик сделал:<br><br>if let Ok(gs) = global_structures.lock() {<br> // то здесь у него есть эксклюзивный доступ к этим структурам через gs<br>}<br><br>Подобный подход наверное не очень хорош, когда речь идёт о файловой системе, но файловая система это лишь один из возможных примеров. А если ты уже получив гарантии эксклюзивности доступа будешь использовать атомарный Arc, вместо Rc, то тебе наплевать на производительность щтоле?<br><br>&gt; placement new не нужна куча.<br><br>А, ты хвастаться знаниями пришёл и докапываешься к словам, ожидая когда я начну комплименты твоему интеллекту и познаниям отпускать? Ты очень умный. И много знаешь. Молодей чувак, круто.<br><br>Но для ясности, давай заменим слово "куча" https://www.opennet.ru/openforum/vsluhforumID3/133278.html#149 Wed, 03 Apr 2024 10:23:26 GMT ЧСХ, из тысячеглаза, только одна пара нашла лютейший ад, который готовился в liblzma.<br><br>Так и живём<br> https://www.opennet.ru/openforum/vsluhforumID3/133278.html#148 Wed, 03 Apr 2024 10:10:17 GMT где-то проводили конкурск на самый короткий и долгокомпилирующийся код на си. там чел каким-то кривым include-ом отправил компилятор на вечную компиляцию<br> https://www.opennet.ru/openforum/vsluhforumID3/133278.html#147 Wed, 03 Apr 2024 09:23:06 GMT &gt;&gt;&gt; Но найти все указатели хранящие данный адрес в общем случае может только<br>&gt;&gt;&gt; сборщик мусора.<br>&gt;&gt; В частном хватает std::shared_ptr&lt;&gt;.<br>&gt; Ты сейчас говоришь про случай описанный в новости, или просто произносишь общую <br>&gt; фразу о том, что иногда все эти сложности решаются при помощи <br>&gt; shared_ptr?<br><br>Вот прямо сейчас я начну говорить о том, что не стоит вырезать контекст (вернул фразу, на которую отвечал).<br><br>&gt; Если первое, то там оно не решается при помощи shared_ptr. Там память <br>&gt; была освобождена, но не была отмаплена.<br><br>Значит решается другим частным случаем RAII, где освобождение всех ресурсов происходит в одной точке?<br><br>&gt; Если второе, то да, иногда shared_ptr помогает, а иногда оказывается таким тормозом, <br>&gt; постоянно сбрасывая кеши, то лучше бы его и не было.<br><br>Это понятно, особенно если он внутри косвенный и с подсчётом ссылок (что не является единственно возможной реализацией).<br><br>&gt;&gt; А Rust что делает? unique_ptr выполняет на этапе компиляции <br>&gt; Неее... В расте есть аналог shared_ptr -- то ли https://www.opennet.ru/openforum/vsluhforumID3/133278.html#146 Wed, 03 Apr 2024 08:44:35 GMT &gt;&gt; Не подходит, код ядра выполняется в произвольном потоке.<br>&gt; Это может быть не важно, в каком потоке он выполняется. Главное чтобы <br>&gt; к Rc не было бы попыток конкурентного доступа из разных потоков. <br><br>Такие попытки как раз и будут. Приложение вызвало syscall, далее поток работает в ядре и лезет куда-то в структуры примонтированной ФС. Они общие для всех? Сколько ещё других приложений делают тот же syscall - неизвестно. <br><br>&gt;[оверквотинг удален]<br>&gt; 1. А в ядре никто и не использует std. Под ядро написана <br>&gt; замена std, которая во многом похожа, но всё же заметно различается, <br>&gt; например Vec::new() возвращает Result&lt;Vec, _&gt;, а не Vec. Я не разглядывал <br>&gt; её, но подозреваю что все эти разговоры про Rc и Arc <br>&gt; туда слабо применимы, потому что в ядре очень востребованы обёртки над <br>&gt; сишными типами с рефкаунтами, и для создания таких обёрток Rc и <br>&gt; Arc бесполезны.<br>&gt; 2. Если в ядре нет кучи, то нет никакого смысла говорить про <br>&gt; shared_ptr, use-after-free, и пр. Когда троллишь, следи за толщиной, п https://www.opennet.ru/openforum/vsluhforumID3/133278.html#145 Wed, 03 Apr 2024 08:36:49 GMT &gt; Ну вот зачем это в ядре по умолчанию, а. Кому оно нужно кроме полутора мегамонстров?<br><br>Ядро-то ? Правильно, никому оно ненужно. В смысле - настолько чтобы платить вашему б-жку с пальцем по ляму долларов в месяц.<br><br>Поскреби по кармашкам - может, найдешь? <br><br>Хахаха! Вот поэтому мы этот дэушка и будим танцыват. Ну и кое что после танцев.<br><br>