https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html В штатной утилите fsck для файловой системы F2FS, предназначенной для работы с накопителями на основе Flash-памяти, выявлены две уязвимости (CVE-2020-6105, CVE-2020-6108), приводящие к перезаписи областей памяти за пределами выделенного буфера при проверке специально модифицированной файловой системы. Уязвимости могут быть эксплуатированы для выполнение кода с правами суперпользователя во время проверки ФС. Проблемы устранены в пакете f2fs-tools 1.14...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53896<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#104 Fri, 23 Oct 2020 19:44:29 GMT а он и не выключал.<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#103 Tue, 20 Oct 2020 09:59:30 GMT &gt; Я про область написания драйверов, т.е. прямая работа с железом.<br>&gt; Вы наверное специально проигнорировали это, привели левые примеры, с некорректным сравнением. <br><br>Признайся, ты драйвера в глаза не видел.<br><br><br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#102 Tue, 20 Oct 2020 09:21:00 GMT Я про область написания драйверов, т.е. прямая работа с железом.<br>Вы наверное специально проигнорировали это, привели левые примеры, с некорректным сравнением.<br>Вести дискуссию с такими приемами я не хочу, поэтому самоотстраняюсь.<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#101 Tue, 20 Oct 2020 04:17:56 GMT &gt; потому что в этой области придется обмазаться unsafe по самое немогу.<br><br>И этот вывод сделан откуда? В работе с файлами, как мы только что выяснили, unsafe присутствует только в одном месте -- FFI (либо raw syscall, либо вызов в libc). Весь остальной код safe.<br><br>&gt; Если я правильно понимаю, часть гарантий раста сохранится,но лишь часть.<br><br>Если твой unsafe блок содержит только FFI вызов, то сохраняются все гарантии. Потому что unsafe это всего лишь блок кода, где разрешены определенные вещи (raw pointers, например, или вызов ассемблерной/сишной функции). Твой растовый код ниже по стеку не становится менее надежным от этого.<br><br>&gt; сильно сомневаюсь, что будет достигнут паритет по скорости с С в данном случае.<br><br>Мьютексы в расте быстрее, чем pthreads. rustls, которая TLS библиотека, быстрее openssl и жрет меньше памяти.<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#100 Tue, 20 Oct 2020 00:09:39 GMT +потому что в этой области придется обмазаться unsafe по самое немогу. Если я правильно понимаю, часть гарантий раста сохранится,но лишь часть.<br>+сильно сомневаюсь, что будет достигнут паритет по скорости с С в данном случае.<br>+через годик другой посмотрим, мб они собственный компилятор и runtime таки доделают. Слишком сырой еще язык<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#99 Mon, 19 Oct 2020 19:28:33 GMT &gt; imho низкоуровневые вещи типа драйверов и прочих все таки еще за C/asm, rust там делать пока что нечего.<br><br>Откуда этот вывод-то?<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#98 Mon, 19 Oct 2020 19:16:22 GMT Ну я прицепился к тому, что без unsafe можно с файлами работать.<br>imho низкоуровневые вещи типа драйверов и прочих все таки еще за C/asm, rust там делать пока что нечего.<br>Мб в будущем ситуация поменяется, но пока так.<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#97 Mon, 19 Oct 2020 16:29:01 GMT &gt; Ну как бы о чем и была в начале речь, без unsafe <br>&gt; вы не можете открыть файл.<br>&gt; Я хз зачем так яростно отстаивать или оправдывать неверную точку зрения.<br><br>Потому что разговор шел в контексте очередной сишной дыры с памятью.<br> https://www.solaris.opennet.ru/openforum/vsluhforumID3/122125.html#96 Mon, 19 Oct 2020 16:12:54 GMT Ну как бы о чем и была в начале речь, без unsafe вы не можете открыть файл.<br>Я хз зачем так яростно отстаивать или оправдывать неверную точку зрения.<br>