From a security/privacy perspective, does it really matter if a Kernel has less code if it's still monolithic? reddit / BSD ---------------------------------------------------------------------- up-sky-7 · 2018-07-23 12:11 No matter how "less code" a kernel has compared to other kernels, we are usually speaking about millions of lines of code. Inspecting and changing such a kernel would require lots of resources. Why aren't security/privacy/freedom-focused kernels adopting microkernels or unikernels? Aside from some performance drops (which I believe someone focused on security & such, would not care) what other drawbacks could be expected? ---------------------------------------------------------------------- rectagonal · 2018-07-23 13:08 > From a security/privacy perspective, does it really matter if a Kernel has less code if it's still monolithic? Security by minimizing code size is about reducing attack surface or the number of attack vectors and often increasing code clarity by reducing complexity and easing the difficulty of auditing the code. It is one facet of how one can approach security. Monolithic/microkernel architectural choices are another. One does not preclude, invalidate or negate the other. > Why aren't security/privacy/freedom-focused kernels adopting microkernels or unikernels? As you posed this question in r/bsd I assume your looking for a BSD specific answer. By and large all the major BSDs (FreeBSD, NetBSD, OpenBSD) are descended from the same historical 386BSD code base. They have all become their own unique codebases serving their respective niche's since then. That being said this is why they do share many similarities inherited from 386BSD such as monolithic kernel architecture. In terms of other OSes... Torvald did not use microkernel design as a conscious choice when creating the linux kernel, [quite famously](https://en.wikipedia.org/w iki/Tanenbaum%E2%80%93Torvalds_debate). There are some unix-like OSes which do toy with microkernel architectures. See Minix and GNU/Hurd. And Haiku for a hybrid design. ---------------------------------------------------------------------- BumpitySnook · 2018-07-23 15:54 Microkernels aren't a magic bullet. The kernel itself would then be easy to verify, but only by virtue of moving everything out of the kernel. You still have almost identical security bugs and code line count, they're just in low level processes instead of "in the kernel." ---------------------------------------------------------------------- vermaden · 2018-07-24 04:17 > Why aren't security/privacy/freedom-focused kernels adopting microkernels or unikernels? Microkernel aren't about security, they are about reliability. When a driver in monolithic kernel (with modules) crashes - it crashes the whole os - kernel panic. When a driver in microkernel crashes, it is just reloaded. > Aside from some performance drops (which I believe someone focused on security & such, would not care) what other drawbacks could be expected? Complexity and dependencies between modules. ---------------------------------------------------------------------- up-sky-7 · 2018-07-24 08:23 Personally I'd love using only microkernels/unikernels since they are easier to be trusted, because they are easier to be inspected *by smaller number of people*. Around a well-developed microkernel I believe would be many developers sharing their unikernel/microkernel modules, just like one can choose in GNU/Linux KDE or XFCE, they could choose a "wifi" module that they like the most, from different devs and built their own custom kernel this way. I know each of these types of kernels have their own advantages and dis. but I'd love seeing other types of kernels being as developed as the monolithic ones, be it BSD or the Linux kernel. Choice is always good. ---------------------------------------------------------------------- rectagonal · 2018-07-24 11:32 > Personally I'd love using only microkernels/unikernels since they are easier to be trusted, because they are easier to be inspected by smaller number of people. I am a fan of microkernels. However, im dubious that this is their security advantage. As the code size or complexity isn't neccesarily greater or smaller than monolithic kernels. You've simply moved much of the code you need to audit to services around the kernel in userland. The security advantage as I see it is containment. It in theory would be difficult to exploit a vulnerability in the userland service or driver and then pivot or escalate to kernel space. However security auditing would still need to take place throughout both the kernel and it's associated services. As this alone does not provide immunity from various other kinds of attacks. Also many people more well versed in OS coding than I am have stated in numerous places that it's easy to overcomplicate microkernel design because of all the message passing. > Around a well-developed microkernel I believe would be many developers sharing their unikernel/microkernel modules, just like one can choose in GNU/Linux KDE or XFCE, they could choose a "wifi" module that they like the most, from different devs and built their own custom kernel this way. Assuming some sort of cross kernel API for such services could be developed and there was interest, perhaps. Though in reality there isn't a reason people can't do this now with monolithic kernels. In fact this is something that goes on now in a limited way more or less with various linux distributions and the BSDs with their derivatives, tuning their kernels with slightly different features via modules and compile time options. > I know each of these kind of kernels have it's own advantages and dis. but I'd love seeing other types of kernels being as developed as the monolithic ones, be it BSD or the Linux kernel. Choice is always good. I get that, ive got a touch of that myself. However scratching current well tested designs that are decades in the making for marginal & not without cost hypothetical improvements is a tough sell, especially for largely volunteer efforts. ---------------------------------------------------------------------- letterafterl14 · 2018-07-24 18:34 How secure would an Exokernel be in comparison to Mono and Micro? I'd assume very secure as with most functions existing outside the kernel (and subsequently outside of ring 0) that would protect against some much more low level attacks, and would overall make the OS itself less comprimisable. Though, as programs have much more direct hardware access that could lead to BIOS viruses becoming more an issue. ---------------------------------------------------------------------- rectagonal · 2018-07-24 19:15 While ive used microkernels and followed developers of a few at various points, ive got zero experience with exokernels. So I must confess i am ignorant there. That being said my best guess is that exokernel and microkernel advantages in terms of security are similar. (Shipping more code out of kernelspace into userland.) ---------------------------------------------------------------------- Kernigh · 2018-07-27 05:38 [Minix 3](http://www.minix3.org/) is the microkernel BSD. Minix runs many of the same programs as NetBSD, but with a different kernel. Minix has user processes (drivers and servers) for things that are part of the kernel in NetBSD. This is why the microkernel of Minix has less code than the monolithic kernel of NetBSD. The microkernel may be more secure if the user processes (drivers and servers) drop privileges. The kernel has full access to the system, but user processes may have less access. Minix has a big drawback: it is missing many things that exist in the monolithic kernels of other BSDs. I have not tried to run Minix, but [I looked at the code of Minix](https://git.minix3.org/index.cgi?p=min ix.git;a=tree;f=minix;hb=HEAD) and suspect that it uses only one processor core (no SMP), has no firewall, and has no USB mouse driver. This is probably because other BSDs have more users and developers than Minix. [Other microkernels](http://www.microkernel.info/) put different things inside or outside the kernel. Minix seems to put forking processes inside the kernel, and scheduling processes outside. GNU Hurd seems to do the reverse, to put forking processes outside, and scheduling processes inside. Monolithic kernels can also put different things inside or outside the kernel. FreeBSD and NetBSD do some audio processing inside the kernel, but OpenBSD does it in a user process [sndiod(1)](https://man.openbsd.org/sndiod). To improve security, sndiod(1) drops root privileges and uses [pledge(2)](https://man.openbsd.org/pledge).