> Меньше больше проблем с CPU не интересно. Результат работы какой с MMU?Я про то что права доступа к памяти вообще-то MMU обрабатываются. Расставлять эти права страницам памяти - дело ядра ОС, кидать исключения при их нарушении - дело процессора. И это разумеется быстро, прозрачно проверяется железом при работе с памятью.
У x86-32 было множество дурных проблем, из-за которых сделать то сразу и прямо - проблема. Например, нет относительных режимов адресации. Поэтому взять программу и подвинуть ее код в другие адреса при старте? Фиг. Там целое действо, на x86-32 вообще надо половину КОДА программы ПАТЧИТЬ до того как запускать. Это "немного" противоречит W^X: как патчить исполняемый код, если записывать нельзя?!
В этом месте замечаем ЧТО x86 позволяет иметь систему странными способами. Скажем пропатчив не сам код а такой х86-изврат как релокейшны и все что вокруг. В этом месте нас начинают волновать RELRO и прочая х86 муть.
А программа в фиксированных адресах памяти с точки зрения безопасности хуже не придумаешь: атакующий сразу точно знает что и где. У менее дурных архитектур включая RISCV с этим сильно меньше проблем - там грузить программы в произвольные адреса намного проще, можно position independent код делать. На x86-32 он не является таковым без адских костылищ.
> Имею ввиду ядро OS + процессор корректно работающие с памятью и
> без потери производительности: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351
И где вот в этом вот всем принципиально требуются именно "специальные команды" какие-то? Для чего? Чего из вон того не реализуемо правами страниц в MMU?
> Покажи тесты: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309
1) Тесты чего именно? В этом списке довольно много.
2) Мы вроде про архитектуру и принципиаьлную (не) возможность сделать там нечто. И в этом месте я хочу обоснование что какие-то там команды какого-то x86 для этого принципиально необходимы. И понимание откуда это следует. Это не про некие тесты.
> И ссылки на код ядра OS корректно работающего с памятью для "современных
> платформ с MMU".
https://kernel.org сойдет? Конечно стопроцентные гарантии сейчас даже страховой полис не дает, но все же. И у конкретно RISCV меньше всего дурного легаси подставляюшего безопасность, если мы об этом.
На RISCV общесистемный контроль наладить сильно проще. Без блобвари в системных аспектах. На интеле очень безопасно с проприетарным биосом/EFI который в любой момент в SMM может уйти, а там еще резидентно блобокод в ME или PSP постоянно активен и может DMA долбануть все и вся если захочет. Да и железки это тоже могут - права памяти на них изначально не действуют, про какие там еще наборы команд они вообще ничего не знают, а стать bus master и записать вон то по конкретному физическому адресу DMA может на раз. Хоть ядро в RAM пропатчив. Современные системы по этому бывают с IOMMU но есть ли он и если да то как настроен - отдельный аспект. Ну конечно мы на честное слово поверим какой-нибудь фирмвари IWL вафли на мегабайт, если не два, умеющей играть в совместную игру с Management Engine для ремотного доступа. Зато покажем красивый тест. Еще вот дергайте пожалуйста всякий ACPI и EFI runtime services, как можно чаще, иначе проприетарные блобы расстраиваются что их надолго на контроль обули. Они конечно могут и сбоку, но тут то как белый человек, на основном проце сразу.
