My wild guess is it reduces the amount of privileged code. In Linux the entire kernel (all 20 million lines of it), can do what it damned well pleases, and auditing 20M lines of code is mission impossible. You could think of it in terms of Windows/OSX/Linux Distro vs Android / iOS / WinPhone. In the former, this is nothing stopping one application stomping over anothers data. The result has been endless uninstallable viruses and malware. The latter force complete almost isolation between applications. What interaction does happen occurs over interfaces that are very heavily policed by the OS (think: is generally doesn't happen without the user giving some permission). The result has been a revolution: almost no one bothers with anti virus software on the phone OS's any more, and any malware you do install can be uninstalled with the click of a button.
Fuschsia, being a micro kernel, puts each functional unit (device driver, network protocol driver, file system, crypto functions, yada yada) into its own isolated process, so the damage a rogue function unit can do is more limited. Interaction between functional units must happen via the Fuschsia kernel (they can't talk directly), and surprise surprise Fuschsia heavily polices those interactions using the "capabilities" provided by the kernel. Capabilities are are very similar to user assigned permissions.
That seems obvious and attractive, but keeping those processes isolated and policing those permissions incurs a overhead, or perhaps more accurately the cost of communication between two isolated processes is much higher than non-isolated (think processes communicating with pipes vs memory sharing threads). In Linux that overhead is still visible as the syscall overhead, which is large enough that high performance applications go out of their way to avoid it. io_uring is another attempt to avoid it. Microkernels multiplies that overhead by many times. Possibly worse, that overhead is getting worse with the advent of spectre like cache timing attacks forcing cache's to be invalidated on a context switch.
In my very brief look at Fuschsia is looked refreshingly clean, small and well thought out. But then all many projects do. Sadly it started like as a C++ code that is now moving towards (as in is now 50%) Rust. To be true to it's safety goals it should all be Rust. And it doesn't seem to bring much new stuff to the table. seL4 has been in the same space for the same reasons for years how. So I don't see how Fuschsia's introduction will change the basic equation that's lead to the dominance of monolithic kernels.
What both seL4 and Fuschsia both desperately need is some magical hardware solution to "isolated process communication" overhead, one that also addresses spectre. Mind you, if a way to isolate code with bugger all overhead came along, it's so attractive I suspect they would be in a race with the existing monolithic kernels to exploit it.
> What interaction does happen occurs over interfaces that are very heavily policed by the OS (think: is generally doesn't happen without the user giving some permission). The result has been a revolution: almost no one bothers with anti virus software on the phone OS's any more, and any malware you do install can be uninstalled with the click of a button.
Taken to its extremes (which Google has been moving Android towards), unfortunately it also breaks a number of existing workflows.
If you follow the documentation, any multi-file formats (HTML documents with their assorted resources – JS/CSS/images/links to other HTML files/..., playlists, videos with externally stored subtitles, multi-part archives, ...) are broken on recent Android versions if you need to handle them in an external app, e.g. if you're writing a file explorer which then naturally needs to call out to other installed apps for actually opening those files.
Fuschsia, being a micro kernel, puts each functional unit (device driver, network protocol driver, file system, crypto functions, yada yada) into its own isolated process, so the damage a rogue function unit can do is more limited. Interaction between functional units must happen via the Fuschsia kernel (they can't talk directly), and surprise surprise Fuschsia heavily polices those interactions using the "capabilities" provided by the kernel. Capabilities are are very similar to user assigned permissions.
That seems obvious and attractive, but keeping those processes isolated and policing those permissions incurs a overhead, or perhaps more accurately the cost of communication between two isolated processes is much higher than non-isolated (think processes communicating with pipes vs memory sharing threads). In Linux that overhead is still visible as the syscall overhead, which is large enough that high performance applications go out of their way to avoid it. io_uring is another attempt to avoid it. Microkernels multiplies that overhead by many times. Possibly worse, that overhead is getting worse with the advent of spectre like cache timing attacks forcing cache's to be invalidated on a context switch.
In my very brief look at Fuschsia is looked refreshingly clean, small and well thought out. But then all many projects do. Sadly it started like as a C++ code that is now moving towards (as in is now 50%) Rust. To be true to it's safety goals it should all be Rust. And it doesn't seem to bring much new stuff to the table. seL4 has been in the same space for the same reasons for years how. So I don't see how Fuschsia's introduction will change the basic equation that's lead to the dominance of monolithic kernels.
What both seL4 and Fuschsia both desperately need is some magical hardware solution to "isolated process communication" overhead, one that also addresses spectre. Mind you, if a way to isolate code with bugger all overhead came along, it's so attractive I suspect they would be in a race with the existing monolithic kernels to exploit it.