The Linux kernel has become very bloated. The compiler used to build it, GCC, is also a vast piece of software. No one person can check all of that code for malware. Even a team would have trouble if attempting to survey all of it. Has there been any effort or just contemplation by you, to deal with the possibility there may now be numerous intentional malware vulnerabilities e.g. backdoors in both the kernel and the compiler, i.e. bugs put there by individuals that you assumed were trustworthy but are not, which enable as-yet unknown ("zero day") hack attacks? I mention the compiler because in the 1990's people spoke of an exploit where the compiler, when it was building the login executable, would add code for a backdoor. Suppose for instance that Ubuntu's build of GCC, which may vary from the source code, were to inject code into the kernel that would, for example, alter a network driver to execute the contents of a specific packet in kernel space e.g. a packet with a certain initial sequence of bytes coming from a certain military contactor's IP range. So the next time you compile the kernel on Ubuntu, you get spyware injected into one network driver for free. One measure to counteract the compiler vulnerability would be to make sure that the kernel also builds fine with a very simple C compiler, e.g. one that is maybe 5000 lines. To achieve better security sometimes one has to embrace simplicity. Doing that with the Linux kernel itself may be difficult since it is so large. If someone were to hide a clever vulnerability in it, it could go undetected for years (indeed one was found I think in BSD recently that lingered for 20 years). As always, we must question assumptions.