Hacker News new | past | comments | ask | show | jobs | submit login

I was looking for a Linus quote I saw on this but can't seem to find it. It's not specifically about security but Linus said something about translation between user and kernel space was an absolute lower bound on performance and you're simply going to do more of that in a microkernel architecture.

Think about it this way: if the TCP stack is in user space then how does another process talk to it to send a packet? Is it directly? Well that has issues. If it's via the kernel then you're already translating to the kernel and then out to user space.

If this is an issue, will the temptation be to make some performance-related bypasses?

Linus of course favours monolithic kernels [1] so consider that a disclaimer.

[1]: https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...




Someone should kill that link, it is no longer a relevant argument. Linus was mostly talking out of his ass complaining about microkernels. His main gripes were specific to Minix and Mach which were popular academic projects at the time.

There are many ways to make microkernels nearly as fast as monokernels, while being much safer and modular with all advantages that entails. See QNX or Sel4 for modern implementations.

Meanwhile, Linux itself has been getting more and more microkernel-y with things like eBPF which because of the monolithic design make the whole kernel much more vulnerable than warranted.


Huh? It’s widely said that microkernels trade performance for security. You seemed earlier to be saying that running core functionality in userspace implies a degradation in security. Typo?


> Think about it this way: if the TCP stack is in user space then how does another process talk to it to send a packet?

In a microkernel system, if a process holds a handle to a TCP stack then it can make calls like create_socket() and then use a socket. For better performance such calls can be executed without visiting the kernel, via call gates. If a process doesn't have a TCP handle, then it cannot access the network which is the best choice for most applications. And of course a privileged enough process can tap into other processes' inter-process calls and see what they are sending and receiving, or even intercept those calls and modify requests and responses, for example, to emulate a network card or to act as a firewall.

In legacy systems like Linux or Windows every process has excess privileges - for example, access to network, to filesystem, to information about other processes, to shared memory, to hardware serial numbers. Linux has several hundreds system calls and they are available to any process. In a microkernel system I am describing the process would have the minimal privileges necessary for its job. For example, a TCP daemon would only have a handle to a router daemon (that redirects packets to a network interface) and no access to filesystem, information about kernel, and so on. Even if this daemon had a vulnerability it wouldn't be of much use for an attacker.


There are user mode TCP stack. It is doable with user mode IPC and IOMMU




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: