> меня больше интересуют generic патчи для mainline, нежели патчи для RHEL.

Нам было бы довольно странно и не очень разумно заниматься поддержкой патчей, которые мы сами бы не использовали (мы сейчас на новые системы ставим почти исключительно RHEL5/OpenVZ ядра - те, что раздаем в Owl). А причину почему mainline бы не использовали Вы назвали сами:

> RHEL5 ядро настолько старо, что обычно 75% уязвимостей его обходят.

Вот, и зачем нам в 4 раза больше уязвимостей? А если кто-то готов на это пойти, то значит у него приоритеты расставлены иначе и security hardening patch ему ни к чему, не так ли? RHEL5 же оказывается для нас оптимальным выбором - с точки зрения поддержки оборудования и нужных технологий там все есть, а с точки зрения уязвимостей это сравнительно старое/стабильное ядро.

С другой стороны, в отношении security hardening для mainline не все так плохо: Dan Rosenberg (Virtual Security Research) и Kees Cook (Ubuntu) недавно составили список изменений из -ow патчей и grsecurity, и еще некоторых "новых" изменений, которые, по их мнению (в целом, совпадающему с моим), должны войти в mainline. Теперь они пере-реализуют эти изменения в форме, пригодной для upstream (добавляют sysctl'ы и т.п.), и постят в LKML по одному, затем участвуют в дискуссиях, доводят до ума/консенсуса и т.д. Вообщем, делают то, что надо. Таким образом уже вошла поддержка dmesg_restrict sysctl и CONFIG_SECURITY_DMESG_RESTRICT, сразу back-port'нулась в ядро для RHEL 5.6, откуда back-port'нулась мной в ядро на основе RHEL 5.5 что мы даем в Owl 3.0. И это только начало. Вот такой круговорот. Зато всё у всех будет. :-) Вот план:

https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening

Я тоже имел наглось кое-что туда добавить. ;-)

А, чуть не забыл, еще в нашей команде сейчас ведется работа над одной дополнительной возможностью ядра "для безопасности". Код изначально делаем для mainline, чтобы предложить его для включения upstream. А уж потом, независимо от результата (включат или нет), сделаем себе back-port.