Это полезная проверка/публикация, и в целом все так и есть, но вывод не столь прост. Упомянутые не-Gentoo дистрибутивы уделяют немало внимания безопасности в других областях, причем более затратных для них, чем просто "подмена" опций сборки программ и подмена ядра. Кстати, кажется, у Debian тоже раздается hardened ядро - просто его почему-то не включили в это исследование.Критериев сравнения дистрибутивов по безопасности может быть гораздо больше, чем просто hardening от выполнения произвольного кода (чисто своего или сконструированного из имеющегося) в предположении наличия соответствующей уязвимости и способа до нее добраться (attack vector). Конечно, это предположение верное, но количество таких сочетаний (уязвимости и способа) для разных дистрибутивов (и вариантов их установки/настройки) будет отличаться, а также будет отличаться скорость исправления уязвимостей после их публикации (а зачастую и до публикации).
К тому же, PIE все-таки имеет ненулевую цену по производительности. Например, в http://d-sbd.alioth.debian.org/www/?page=pax_pie приводится оценка в 5.8% для одного из вариантов сборки под 32-битный x86. В приведенном исследовании речь шла как раз о 32-бит. (На x86-64, по информации с той же ссылки, замедления почти нет.)
grsecurity/PaX - это, предположим, хорошо, но кто и на каком основании в такой компании как Red Hat или Novell возьмет на себя ответственность за большой объем не-upstream изменений в ядро, которые аудиту толком не подвергнешь (кто пробовал этот код читать, тот знает почему)? "Я пил пиво с авторами на таком-то con'е и теперь готов поручиться" - что скажут на это клиенты?
Возможно, ситуация была бы иной если бы когда PaX только начал появляться, к нему был бы интерес со стороны mainstream, но это тогда было нереально, как и к моему non-exec stack patch несколькими годами ранее. А несколькими годами позже аудит и включение PaX уже было нереальным по причине объема и сложности кода (вернее, нетривиальности причин, стоявших за на вид простыми изменениями кода), разрабатывавшегося в одиночку. (Возможно, если бы автор попытался вежливо, "самопожертвенно", но целенаправленно и активно давать в upstream отдельные патчи для отдельных вещей, как это, например, стали делать OpenVZ, результат был бы во многом иным. Но я понимаю, что в целом это неблагодарное занятие.) Появился exec-shield, который этих недостатков не имел, но обеспечивал менее полную защиту (частично из здравых соображений, таких как отсутствие замедления и сложных изменений кода), что мы здесь и видим.
