> И в случае pledge, и в случае PaX за гарантии отвечает ядро.Нет, в OpenBSD ядро не дает никаких гарантий, оставляя возможность приложениям изменять исполняемый код. Это дыра которую будут использовать вири.
> В случае pledge, гарантии заказываются из кода программы,
Это смешно. Гарантии неизменности исполняемого кода должно давать ядро или аппаратно проц.
> в случае PaX - через paxctl/конфиг ядра.
Ядро с PaX дает гарантии неизменности исполняемого кода и гарантии невозможности отключения такого поведения для всех программ.
В тоже время есть возможность выбора:
1. Дополнительно добавить в ядро возможность исключения для некоторых программ помеченных через заголовок ELF или расширенные атрибуты файловой системы xattr (PeMRs).
Pp - постраничная защита памяти.
Ee - эмуляция трамполлайнов. Очень маленькие участки памяти которые можно переводить в режим WX
Mm - защита памяти. В частности гарантия W^X. Выше упоминал все гарантии mprotect при использовании PaX ядра.
Rr - рандомизация адресного пространства.
Ss - посегментна защита памяти, если постраничная не поддерживается процессором (NX инструкция) или мы не доверяем защите памяти реализованной процессором.
По умолчанию ядро с PaX дает максимальную защиту.
2. Дополнительно добавить в ядро возможность загружатся в режиме когда PaX ядро не блокирует, а только ведет журнал событий нарушающих нормальное использование памяти. Grsecurity ядро блокирует изменение рабочего ядра через sysctl и следовательно дает гарантии невозможности включать/выключать PaX softmode в случае его поддержки ядром.
> > Были, есть и будут OS общего назначения и прикладные программы которые строго соблюдают правила контроля за оперативный памятью.
> Только никакого успеха они не имеют (чего нельзя сказать про нишевые решения).
Среди тех которые ты должен знать упомяну Apple как фирму чьи OS очень строго защищают память.
Также MS Windows имеет защиту оперативной памяти, но менее строгую по сравнению с Apple. MS видать как и Тео с OpenBSD попросили пойти на компромисс и просверлить дырочки, для "повышения производительности".
> Нельзя сказать, что ситуация совсем не меняется, но даже там, где стало можно, например, выключать JIT, требующий нарушения W^X, это всё равно не используется как вариант по-умолчанию
Самое главное, разработчики поняли, что код с JIT есть небезопасен, непортабелен и просто на некоторых аппаратных (powerpc,mips,..) и программных (Linux+PaX, Apple, ...) не работает. Для этих програмно-аппаратных архитектур есть возможность отключать код JIT еще на этапе конфигурации исходников перед сборкой и он используется по умолчанию всегда.
> и закономерно обладает меньшей производительностью.
Это очень спорный вопрос. Вас обманывают воруя безопасность и обещая мнимую производительность! Изменения режима исполняемого кода на изменяемый и потом обратно это очень ресурсоемко и врят ли окупится.
Оптимизация программы в момент компиляции под целевой процессор дает максимум производительности и скорости исполнения. В добавок можно получить гарантию неизменности исполняемого кода- безопасность.
