>> Меньше больше проблем с CPU не интересно. Результат работы какой с MMU?
> Я про то что права доступа к памяти вообще-то MMU обрабатываются. Так, по жизни. Расставлять эти права страницам памяти - прерогатива ядра ОС, кидать исключения при их нарушении - дело процессора. И это разумеется быстро, прозрачно проверяется железом при работе с памятью.Список архитектур, процессор + ядро OS которые обеспечивают __корректную__ работу с памятью со ссылками на исходники ядер?
Критерии корректности работы ядра OS c памятью: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351
W^X это фундаментальный и принципиальный момент для безопасности архитектуры:
"Все что исполняется никогда не должно изменятся, а что изменяется никогда не должно исполнятся" - это правило основа всей ИТ безопасности.
из него следует:
1. запрет изменения на исполняемую области памяти которая исполняемой не создавалась (W^X),
2. запрет изменения на запись памяти которая выделена как исполняемая (W^X),
3. запрет создания исполняемой памяти из анонимной памяти (W^X),
4. запрет изменения на запись памяти выделеной только для чтения (RELRO).
>[оверквотинг удален]
> другие адреса при старте? Да сейчас! Там при этом целый комплекс танцев с бубном. И при этом на x86-32 надо половину КОДА программы ПАТЧИТЬ до того как его запускать. Это "немного" противоречит идее W^X: а как патчить исполняемый код, если туда записывать нельзя? В этом месте мы еще замечаем что x86 порнография позволяет иметь систему странными способами. Скажем пропатчив не сам код а такой х86-изврат как релокейшны и все что вокруг. В этом месте нас начинают волновать RELRO всякие и прочая х86 муть.
> Если это не делать, программа в фиксированных адресах памяти с точки зрения безопасности хуже не придумаешь: атакующий сразу точно знает что и где.
USE="pic pie"
CFLAG="-fPIE -fPIC"
Трудно, да...
Держи пример x86-32 где всё работает правельно: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
Грузи и запускай тесты: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309 видишь тесты проходит!!!
> У менее дурных архитектур включая RISCV с этим сильно меньше проблем с самого начала - там грузить программы в другие адреса сильно проще.
Теперь покажи мне пример дистра для RISC-V который может пройти эти тесты: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309
Покажи результаты аудита lynix для RISC-V
Ах не может архитектура W^X ?!! Разарбы в RISC-V засунули аппаратный троян: вместо стандартных прав RWX на выделяемую память сделали RW_изменение_памяти_ : https://www.opennet.ru/openforum/vsluhforumID3/129886.html#323
>> Имею ввиду ядро OS + процессор корректно работающие с памятью и
>> без потери производительности: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351
> И где вот в этом вот всем принципиально требуются именно "специальные команды" какие-то? Для чего? Чего из вон того не реализуемо правами страниц в MMU?
Реализуй вот эти критерии: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351 и дай ссылку на исходники ядра OS.
>> Покажи тесты: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309
> 1) Тесты чего именно? В этом списке довольно много.
> 2) Мы вроде про архитектуру и принципиаьлную (не) возможность сделать там нечто а это немного не про конкретные тесты конкретной конфиги а про принципиальную (не)возможность это сделать.
Покажи эти тесты: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309 для RISK-V. Там мало тестов. Lynix можешь не запускать.
>> И ссылки на код ядра OS корректно работающего с памятью для "современных платформ с MMU".
> https://kernel.org сойдет?
НЕТ! "ссылки на код ядра OS __корректно работающего__ с памятью". Критерии корректности работы ядра OS c памятью: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351
Пример результатов тестов, для корректной архитектуры: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309
> Конечно стопроцентные гарантии сейчас даже страховой полис не дает, но все же.
У тебя плохая страховая и плохой договор.
> И у конкретно RISCV меньше всего дурного легаси подставляюшего безопасность, если уж на то пошло.
Где аудит и результаты тестов? Без них для меня у конкретно RISC-V меньше всего безопасности.
> Даже у ARM каких например безопасность может быть снижена всякими фиксироваными call table по общеизвестным адресам если compat с более старыми форматами бинарей надо. Можно запретить - но тогда кернел не сможет более старые программы EABI запускать. Вот и выбирают люди между секурити и работоспособностью и совместимостью. И вот именно паксов целиком в майнлайн не берут потому что много чего ломается.
Это проблемы проприетарщиков, которым лень для клиента пересобрать пакет под новую архитектуру. Да, знаю таких лично, от покупки их софта отказались именно по причине __не__ __желания__ пересобрать под новую архитектуру проца.
> В остальных случаях... интересно, много вам радости с команд если там чего доброго с Management Engine отменеджат с условного "ring -3" всякие супербоги? Безопасность - штука весьма комплексная. Системы на RISCV в 20 раз проще в понимании, без ME/PSP и прочих SMM mode в проприетарной фирмваре, там весь системный уровень самому реально обыграть. А у какого-нибудь интела еще может быть бонусом какая-нибудь iwl вафля с фирмварой сервисного проца на пару мегов - умеющая в DMA и интегрирующаяся с ME для предоставления ему комуникационого канала.
Бери железо с LibreBOOT. Да аппаратные трояны ещё хуже чем плохие архитектуры.
> Ну и кто будет ломиться лобовым способом обходя все эти DEP если например можно вон оттуда просто DMA зафигачить? На DMA вообще права доступа к памяти могут не действовать - он не проц, MMU по пути нет, о "командах проца" он вообше ничего не знает. В лучшем случае у платформы будет такая штука как IOMMU, это реверсный вариант, проверяющий права доступа уже когда железо -> RAM лезет. Но это опциональная штука и даже когда он есть, сильно отдельный вопрос как он там настроен и насколько он там эффективный. В кернеле на этот счет забавные дефолты есть.
Для борьбы с этим разрабатывают https://muen.sk/ Можно делать CPU+Muen+GNU/Linux
> Я это к тому что вы не контролируете низкоуровневый системыный уровень безопасности, менеджмента и проч позволяюший вынести всю систему - но при этом паритесь какими-то костыликами. Это очень странный взгляд на системную безопасность, в том смысле что вы игнорите десятки способов раздербанить систему и выпячиваете какие-то костыли как нечто офигенное. На x86 вообще проблематично получить реально доверяемую и безопасную систему где не надо "доверять" хрен знает каким
блобам делающим черт знает что в самых критичных местах системы. А чтоб не скучно было EFI еще и рантайм сервисы умеет, чтобы блобварь не отваливала не только с ME/PSP/сервисных процов но и более прямой доступ к основному имела.
Бери железо с LibreBOOT. Делее CPU+Muen+GNU/Linux+PAX
Это https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309 не костыли, а простая, корректно работающая система. Странный взгляд на безопасность у вас с виртуализацией, MAC, .... и без настройки минимальных требований DAC.
