https://opennet.dev/openforum/vsluhforumID3/129886.html Компания Microsoft открыла наработки, связанные с проектом CHERIoT (Capability Hardware Extension to RISC-V for Internet of Things), нацеленным на блокирование проблем с безопасностью в существующем коде на языках C и С++. CHERIoT предлагает решение, позволяющее защитить существующие кодовые базы на С/C++ без необходимости их переработки. Защита реализуется через применение модифицированного компилятора, использующего специальный расширенный набор процессорных инструкций (ISA), предоставляемых процессором и на аппаратном уровне отслеживающих доступ к памяти, проверяющих корректность работы с указателями и обеспечивающих изоляцию блоков кода...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58726<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#359 Thu, 04 Jan 2024 20:25:42 GMT &gt;&gt;Диды (K&R) говорили что просто int может быть по умолчанию или signed или unsigned.<br>&gt; Мощное заявление, пруфов конечно же не будет.<br><br>Да, память меня подвела, признаю, распространил я в своей голове поведение char на все int (целыe).<br><br>Я, когда все это читал, не захотел зазубривать всякие тонкости преобразований по умолчанию и потом при написании кода это еще крутить в голове до/вместо компилятора.<br>Поэтому вывел для себя это правило - писать как если бы signed или unsigned по умолчанию был не определен.<br>Вот если уже без конкретного подозрительного преобразования не обойтись - то представлять как процу/компилятору это легче сделать - он скорее всего так и сделает. Или просто смотреть нагенерённый асм.<br><br>А вообще там интересна, главная фраза<br>"The int types all represent signed values unless specified otherwise."<br>Specified видимо стоит читать как "не написано рядом unsigned спецификатора"<br>Хотя можно было бы в порядке троллинга и поспорить что мол не специфицировано мануалом на проц/компилятор.<br><br>НО, к https://opennet.dev/openforum/vsluhforumID3/129886.html#358 Thu, 04 Jan 2024 19:32:40 GMT &gt;Диды (K&R) говорили что просто int может быть по умолчанию или signed или unsigned.<br><br>Мощное заявление, пруфов конечно же не будет.<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#356 Sun, 17 Sep 2023 14:01:23 GMT &gt;[оверквотинг удален]<br>&gt;&gt; Я по быстрому просматривал документацию,этого там нет.<br>&gt; Значит RISC-V - _г_о_в_н_о_ проц.<br>&gt;&gt; Но если нужна защита есть хитрый атрибуты для атомарной операции.<br>&gt; И как ты без NX будешь защиту памяти писать в OS? Надо <br>&gt; реализовать: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#253 <br>&gt; Писали когда-то защиту и для 286 без NX, но с какими-то другими <br>&gt; инструкциями, регистрами - тормоза, ад и израиль!<br>&gt; Переписывать ядра OS никто не будет. Защита памяти уже реализована постранично или <br>&gt; посегментно. Если проц не умеет ни постранично ни посегментно, то такое <br>&gt; _г_о_в_н_и_щ_е_ никому ненужно!<br><br>Не было там никаких тормозов, NX можно реализовать через отдельный tlb для выполнения, там было что-то вроде выставить атрибуты страницы, выполнить инструкцию или выставить и прочитать, тогда в кеше для выполнения и чтения/записи были разные атрибуты страницы (no_access/rw) что-то в этом роде<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#355 Sat, 24 Jun 2023 05:58:21 GMT Тесты RISC-V покажи: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309<br><br>Важно иметь архитектуру CPU + ядро OS. В ядре OS тоже необходимо реализовать DAC для защиты оперативной памяти.<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#354 Sat, 13 May 2023 15:52:49 GMT &gt; То, что в RISC-V засунули 3 бита для чтения, изменения, записи вместо <br>&gt; чтения, ИСПОЛНЕНЯ, записи - выглядит как умышленное вредительство, аппаратный троян.<br>&gt; Необходимый NX зажидили, но при этом инструкции виртуализации и сабж, включили.<br>&gt;&gt; А насчет неисполняемого бита - еще для х86 было такое замечательное решение PaX.<br><br>Какое необразованное, наглое вранье. Чем лапшу вешать людям на уши или коль сам веришь в то что говорит, заглянул бы в спеку priv, на эмуляторе посмотрел бы поведение в конце концов.<br><br>(Figure 4.15) The permission bits, R, W, and X, indicate whether the page is readable, writable, and executable, respectively.<br><br>https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#353 Thu, 11 May 2023 12:27:12 GMT Инструкция PAE в процах Intel позволяет делать ASLR без потерь производительности.<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#352 Tue, 04 Apr 2023 17:50:03 GMT Я писал в контексте вопроса "&gt;А зачем индекс signed делать вообще?! Кто-нибудь объяснит мне это вообще?"<br>И написал в том числе "И если нет разницы, то пиши int, будет быстрее, точно не медленнее."<br>Еще раз - "И если нет разницы" и про (K&R) C.<br>Т.е. если это индекс массива в аргументе функции и надо hint - так вот и пиши unsigned int, кто ж за руки держит.<br>И доку/маны тогда все же писали и читали, не то что сейчас "все самодокументировано", действительно замучаешься читать код либ.<br><br>А по большому счету - так я с твоими доводами согласен, в смысле что в нынешних условиях можно и получше.<br>Только когда K&R C придумывали, весь UNIX крутился на 64 KB и не жужжал.<br> https://opennet.dev/openforum/vsluhforumID3/129886.html#351 Tue, 04 Apr 2023 15:34:17 GMT &gt; Линукс портабельная система. Вот лично меня линукс интересует на ARM (-el,-hf,aarch64), MIPS, RISCV, x86-64. Итого 6 (суб)архитектур. С своими идеями как там и что. И я предпочту чтобы секурно было более-менее везде, ага. <br><br>Классический алгоритм постраничной защиты памяти с использованием инструкции NX и без потери производительности работает на архитектурах: alpha, avr32, i386, ia64, parisc, sparc, sparc64, x86_64.<br><br>На ppc, ppc64 там чуть по другому зделано, другая архитектура и постранична защита памяти будет чуть-чуть тормозить.<br><br>MIPS реализацию постраничной защиты памяти давно начинали писать за результат не знаю, но потери производительности чуть будут.<br><br>ARM слыхал материли, он о энергопотреблении, а не о безопасности. Проц разрабатывался не для работы с тяжолыми правельными ядрами. Разрабы ядер задавали вопросы ARM "а как вы понимаете безопасность". Потом вышел hardfp и от ARM отстали. ARM для экономии энергии и денег, а не для безопасности.<br><br>RISC-V - https://www.opennet.ru/openforum/vsluhfo https://opennet.dev/openforum/vsluhforumID3/129886.html#350 Mon, 03 Apr 2023 17:09:36 GMT На все отвечать не буду, но прочёл всё.<br><br>&gt; JIT не будет работать с W^X. Почему-то. Data2code transform тоже не будет. <br><br>W^X это фундаментальный и принципиальный момент для безопасности архитектуры.<br>"Все что исполняется никогда не должно изменятся, а что изменяется никогда не должно исполнятся" - это правило основа всей ИТ безопасности.<br><br>&gt;&gt; Google Chromium имеет JS движок без JIT, <br>&gt; А вы им еще и пользоваться пробовали?<br><br>На многих архитектурах с W^X люди пользуются.<br><br>&gt;&gt; с DAC, которые запретят запустить бинарь собраный/скачаный пользователем.<br>&gt;&gt; Система разрешает запуск только корректно установленного ПО. Но это уже другая история.<br>&gt; Это все прекрасно - кроме того что с одной сторонй DAC достаточно хлипкий и уповать только на него да ну нафиг.<br><br>Второй фундаментальный принцип ИТ безопасности утверждает, что сначала необходимо настроить DAC. Правельно настроеный DAC даёт вполне безопасную систему.<br><br>И только после настройки DAC стоит заморачиватся c MAC и прочим.<br><br>Сами технологии виртуализации н