> Зависит от того, что имеется ввиду под программной и под аппаратной защитой.
> Современные (маргинальные ;) языки с безопасными типами и среды на их
> базе с программной изоляцией задач гораздо безопаснее аппаратных костылей Все бы ничего, но в таковых средах, типа Java/.NET/PHP/whatever ... почему-то находят уязвимости, пачками. Колосс получается на глиняных ногах. А общая монструозность таких сред заведомо гарантирует что там будут кучи багов. ИМХО большой вопрос что там дырявее окажется: демон на 10 кило на си, или демон на 10 кило на типобезопасном языке + 100 мегов среды этого типобезопасного (писаные как правило на все тех же типоопасных сях).
> (как раз они реализованы в PaX и т.п.) для приложений на языках с
> небезопасными типами, вроде C/C++.
Хз, почему-то все хотят видеть панацею в таких языках, но по факту - как-то сильно лучше не становится. Ну да, там вместо переполнений буферов - sql injection, php includes всякие и т.п.. И даже назойливый XSS как оказалось может быть более зловредной штукой чем можно полумать: AFAIK, кто-то пустил по твиттеру саморазмножающегося червя на JS, который будучи выполненым жертвой ... постит сам себя заново. Вполне себе этакое самоходное ПО :). В общем старые проблемы решили (если бы :D), новых насоздавали.
> На некоторых архитектурах, включая x86, защиту страниц/регионов памяти от выполнения можно
> реализовать и без NX-бита.
Ну вообще да, я тут погорячился - перерезус тут уже зацитировал про реализацию с CS. Это видимо даже катит, хоть и костыль в духе x86, как обычно :)
> Бенчмарками приложений, решающих конкретные поставленные задачи, до и после внедрения
> SSP (и других подобных мер). Это элементарно.
А результаты сообщить не хотите для разных программ?
> Да не надо их определять - надо тестировать и выявлять узкие места.
> И выявляются они отнюдь не в SSP.
Вообще, звучит разумно.
