Nonsense the kernel owns huge swaths of the IO path. For example: It is responsible for all ethernet and IP layer operations, and handles TCP, etc. (By defaul

Nonsense the kernel owns huge swaths of the IO path. For example: It is responsible for all ethernet and IP layer operations, and handles TCP, etc. (By default, there's ways to move these things into userland, but in 99% of cases, programs open a socket, and exchange buffers with the kernel - the kernel does the rest). You're telling me that the kernel should not be a security boundary against malformed packets? That it's no big deal if some malformed packet can crash a machine, cause remote code execution, or cause the system to perform poorly (all real things that have been possible in most tcp/ip stacks, including linux)? Hell (ip|nf)tables firewalling is a security boundary, and it is implemented in the kernel. If you configure a rule and the kernel code handling that rule has a bug that allows bad traffic - isn't this a case of the kernel literally advertising itself as a security boundary and failing? This is where some genius usually steps in and says "well thats why you use a hardware firewall hurr durr - but those are just boxes running a tcp/ip stack with help from some chips that can assist the operations. Problems there: * The hardware or firmware or even the linux kernel running on such boxes may also have bugs, letting bad traffic through to the hosts/servers. * There are categories of network stack bugs with packets that look like good traffic that can still be exploited on the host's kernel. (Aka defense in depth requires the kernel to be the best security boundary it can be also).