>> Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть.
> Классика жанра:
> В спец ПО для райнимации больного допустили ошибку переполнения буфера или даже ядро OS имеет ошибку переполнения буфера. Вирус использует эту уязвимость переполнения буфера и ядро с W^X убивает процесс поддержки жизнедеятельности человека. Человек погибает, а компьютер остается не зараженным.

Логика рассуждения мне понятна, спасибо. Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например. Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда?
Или, например, можно не использовать динамических алокаций вообще, если условия задачи позволяют.
А PaX не обязательно убивает процесс, тот же PaX MPROTECT, про который тут шла речь, приводит к тому, что mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы.

> В случаях когда работа сервиса имеет приоритет над безопасностью, жесткий контроль за памятью использовать нельзя. Просто журналируются все события некорректного поведения процесса, без каких либо санкций к нему.
> Это надо обязательно понимать и помнить.

В моём понимании, это не напрямую связанные вещи. Если конструкция в целом умеет переживать смерть отдельного процесса без остановки сервиса, то не вижу проблем даже и в прибивании за нарушение гарантий памяти. Если не умеет, то мы нарвёмся на проблемы и без проблем с безопасностью.

Требование-то, на самом деле, к непрерывности предоставления сервиса, а не к модели памяти. От этого, имхо, и нужно рассуждать.