oui ca existe deja, et c'est bien plus compatible qu'un kernel e zero: Free/Net/OpenBSD.

Pour la compatibilité, oui. Pour améliorer significativement la sécurité, les BSDs dérivés d'une base de code plus vieille que Linux et écrite dans le même langage difficile à sécuriser ne sont pas vraiment une meilleure solution que Linux. OpenBSD est considéré comme le moins mauvais, mais sa réputation de sécurité est largement usurpée: spender les défonce assez régulièrement pour ce qu'ils font mal ou peu utilement (W^X, pledge, KARL, etc.), ou encore, la première tentative de faire tourner (pas très longtemps) un fuzzer sur OpenBSD s'est soldée par une dizaine de bugs graves, dont un DoS complet du kernel par un utilisateur non privilégié.
L'ajout des fonctionnalités kernel permettant d'implémenter des mitigations user-space est nettement en retard sur les BSDs: il a fallu 6 ans à OpenBSD pour mettre quelque chose d'aussi faible qu'ASLR après que PaXTeam l'ait inventé (seulement 1 an pour Windows et Linux), 13 ans ou plus (!) aux autres BSD - et certains ne doivent même pas encore l'avoir. Idem pour le sandboxing basé sur les blacklists ou whitelists de syscall. Pour Linux, seccomp mode 2 est difficile à utiliser, probablement de granularité trop fine (alors que pledge est trop grossier), mais au moins, il existe.

Si on peux faire avec du code "neuf" qu'on ne maitrise qu'a moitié, on peux aussi le faire avec du code plus ancien, mais mieux maitrisé.

Nous sommes d'accord, on peut le faire en y passant suffisamment d'effort. Du code plus ancien mais mieux maîtrisé, c'est ce que PaX + grsecurity font depuis 16 ans. Et pour plusieurs raisons, pas toutes bonnes, même du temps où le patch était publiquement disponible, seule une faible minorité d'utilisateurs en tirait parti, et ils n'arrivaient pas à vivre de leur travail. Je ne sais même pas s'ils y arrivent maintenant.
Le problème, c'est qu'il semble qu'on ne va pas le faire, en ce qui concerne Linux. Le groupe des principaux mainteneurs du kernel est assez fermé et n'est pas compétent en sécurité, ceux qui travaillent sur le KSPP n'arrivent pas à rentrer les choses les plus utiles pour des raisons politiques et ne sont pas assez compétents pour rentrer correctement des choses moins invasives et de plus faible valeur de protection. Ca ne prend toujours pas le chemin de rendre beaucoup plus étanche le code utilisé par la majorité des utilisateurs de Linux, et sans un difficile changement complet des mentalités (et des personnes ?), ainsi que de gros investissements, ça n'en prendra "jamais" le chemin.