Des compromis comme micro-kernel vs. kernel monolithique peuvent être revisités, en effet. C'est plus facile de sécuriser un tout petit code, voire de le vérifier formellement: seL4 l'est depuis des années, même s'il a des axiomes comme un fonctionnement correct des registres du processeur et de la MMU, ce qui n'est d'ailleurs pas le cas sur beaucoup de processeurs modernes avec exécution OOO spéculative. Mais la compatibilité avec l'existant, d'une part, et/ou la performance brute, d'autre part, pèsent plus lourd que tout.

Non pas que la performance soit nécessairement un problème intrinsèque des micro-kernels - cf. les papiers SOSP'93 et SOSP'95 de Jochen Liedtke, qui montrent que le mini-kernel largement indépendant hardware est une mauvaise idée, et que pour moins polluer le cache, il faut des choses plus minimalistes - mais une sécurité accrue va souvent de pair avec une moindre performance brute, et une réduction de la compatibilité avec les machins non sécurisés. Voir PaX+grsecurity: KERNEXEC + MEMORY_UDEREF, qui ne nécessitent pas x86 PCID, SMEP & SMAP / ARM PXN & PAN mais peuvent en tirer parti, et ont un coût en performance. Ou encore PaX MPROTECT (et le LSM S.A.R.A jamais intégré au kernel Linux), que les moteurs JIT pour JS des browsers habituels n'aiment pas, nécessitant de débrayer cette protection pour les browsers, qui restent de façon constante parmi les plus grosses passoires présentes et utilisées intensivement sur les ordinateurs utilisés par la plupart des utilisateurs humains.