SII писал(а):
Она в любом случае может произойти. ИМХО, достаточно обычной защиты памяти: для чужих областей...
Что значит "чужих областей"? Я говорил о стеках многопоточного приложения. Слишком глубокий стек может наложиться на другой стек или лежащие под ним данные.
Что касается разделения областей по назначению, то часто аппаратура не позволяет выставить абсолютно все требуемые для секции атрибуты. Я например не требую, чтобы приложение обязательно использовало стек, расположенный в стековой области. Оно может переопределить указатель стека на область данных, но тогда автоматически уменьшается гарантия того, что при наложении стека на данные возникнет исключение или что стек будет неисполняемым, т.к. данные у меня сейчас всегда исполняемые (IA-32), потому что иначе было бы невозможно в адресном пространстве приложения запустить какой-либо модуль кроме основного (секции отдельного модуля по возможности группируются вместе). Неисполняемой может быть только стековая область, да и то это не гарантированное поведение системы, а бонус конкретной версии ядра. Что касается "чересполосицы", то ядру ее нетрудно обеспечить, выставляя нужные атрибуты для соответствующих страниц. Другое дело, управление прикладными стеками на уровне ядра, как цельными объектами. Сейчас это реализовано в ядре, но я не исключаю вынос подобных функций на прикладной уровень в будущем.
418ImATeapot писал(а):
Провокационный вопрос: а через сегменты не проще?
Не проще. Все, что за гранью FLAT-адресации, не проще. Поэтому и приходится шаманить с сегментами, чтобы и их по возможности задействовать и остаться в рамках FLAT-адресации. К тому же не следует забывать о 64-разрядной архитектуре с практически полностью вырожденной сегментацией.