3 ms·

The choice of a pure-monolithic kernel is also interesting; I can buy that it's more secure, but having to recompile the kernel every time you change hardware s

The choice of a pure-monolithic kernel is also interesting; I can buy that it's more secure, but having to recompile the kernel every time you change hardware sounds like it would be pretty tedious. Early days, though, so we'll see how that decision works out.

Rohansi 1y ago
Why would you need to recompile if hardware changes? Linux manages just fine as a monolithic kernel that ships with support for many devices in the same kernel build.
- ofrzeta 1y ago
  It's true that you can compile everything in but it's not really the standard practice. On a stock distro you have dozens of dynamic modules loaded.
  - ori_b 1y ago
    OpenBSD removed support for loadable modules. Hardware today is big enough that compiling everything in is fine, and we don't need a ton of fiddly code to put a special-purpose linker into the kernel. Saving a bit of memory isn't worth the risk.
  - LavenderDay3544 1y ago
    Even a fully loaded kernel with loads of drivers isn't that big. And not all of it has to be resident in memory at all times. Code in general is miniscule compared to data. And most of a kernel's data isn't baked into the executable. And this kernel in particular has very thin drivers that only abstract real devices to generic device class interfaces that userspace has to deal with directly. That's the part that's inspired by exokernels and hypervisor paravirtualization. That means that drivers for this kernel will be even smaller than those for other ones like Linux.
vlovich123 1y ago
Why would you buy it’s more secure. Traditionally in windows in-kernel compositing was a constant source of security vulnerabilities. Sure rust may help the obvious memory corruption possibilities but I’m not convinced.
- LavenderDay3544 1y ago
  [flagged]
  - vlovich123 1y ago
    I’m really not sure what I said that warranted this reaction. I was literally talking about Microsoft moving the compositor that was inside the kernel in their old Windows 9x kernel architecture to outside the kernel in Windows NT. That literally every other kernel (OSS and comercial, Unix and not) does this separation suggests this is a generally accepted good security practice. I’m not aware of any kernel research that alters the fundamental fact that having compositing in-kernel compositing is a big security risk surface area and the OS you are proposing isn’t even pure Rust - it’s got C and assembly and unsafe Rust thrown in which suggests there’s a non trivial attack surface area that isn’t mitigated architecturally - AFAIK capability security won’t help here with a monolithic design and you need a microkernel design to separate concerns and blast areas to make the capabilities mean anything so that an exploit in one piece of the kernel can’t be a launching pad to broader exploits. This is also ignoring that even safe Rust has potential for exploit since there are compiler bugs around soundness in terms of generated code so even if you could write pure safe Rust code (which you can’t at the OS level) a monolithic kernel would present issues. TLDR: claiming that there’s decades of OS research to improve on that existing kernels don’t take advantage of is fair. Claiming that a monolithic kernel doesn’t suffer architectural security challenges, particularly with respect to compositing in-kernel is a bold statement that would be better supported by explaining how that research solves the security risks rather than launching an ad hominem attack against a different kernel family than I even mentioned is just a weird defensive reaction.
    - LavenderDay3544 1y ago
astrange 1y ago
A monolithic kernel and resource locators that automatically mount network drives? That's just macOS. (You don't have to recompile the kernel if you put all the device drivers in it, just keep the object files around and relink it.)
LavenderDay3544 1y ago
Incremental compilation makes that a lot less heavyweight than you would think and the idea is to automate the process so the average non-technical user doesn't need to know or care how it works.

Rohansi 1y ago

Why would you need to recompile if hardware changes? Linux manages just fine as a monolithic kernel that ships with support for many devices in the same kernel build.

ofrzeta 1y ago
It's true that you can compile everything in but it's not really the standard practice. On a stock distro you have dozens of dynamic modules loaded.
- ori_b 1y ago
  OpenBSD removed support for loadable modules. Hardware today is big enough that compiling everything in is fine, and we don't need a ton of fiddly code to put a special-purpose linker into the kernel. Saving a bit of memory isn't worth the risk.
- LavenderDay3544 1y ago
  Even a fully loaded kernel with loads of drivers isn't that big. And not all of it has to be resident in memory at all times. Code in general is miniscule compared to data. And most of a kernel's data isn't baked into the executable. And this kernel in particular has very thin drivers that only abstract real devices to generic device class interfaces that userspace has to deal with directly. That's the part that's inspired by exokernels and hypervisor paravirtualization. That means that drivers for this kernel will be even smaller than those for other ones like Linux.

vlovich123 1y ago

Why would you buy it’s more secure. Traditionally in windows in-kernel compositing was a constant source of security vulnerabilities. Sure rust may help the obvious memory corruption possibilities but I’m not convinced.

LavenderDay3544 1y ago
[flagged]
- vlovich123 1y ago
  I’m really not sure what I said that warranted this reaction. I was literally talking about Microsoft moving the compositor that was inside the kernel in their old Windows 9x kernel architecture to outside the kernel in Windows NT. That literally every other kernel (OSS and comercial, Unix and not) does this separation suggests this is a generally accepted good security practice. I’m not aware of any kernel research that alters the fundamental fact that having compositing in-kernel compositing is a big security risk surface area and the OS you are proposing isn’t even pure Rust - it’s got C and assembly and unsafe Rust thrown in which suggests there’s a non trivial attack surface area that isn’t mitigated architecturally - AFAIK capability security won’t help here with a monolithic design and you need a microkernel design to separate concerns and blast areas to make the capabilities mean anything so that an exploit in one piece of the kernel can’t be a launching pad to broader exploits. This is also ignoring that even safe Rust has potential for exploit since there are compiler bugs around soundness in terms of generated code so even if you could write pure safe Rust code (which you can’t at the OS level) a monolithic kernel would present issues. TLDR: claiming that there’s decades of OS research to improve on that existing kernels don’t take advantage of is fair. Claiming that a monolithic kernel doesn’t suffer architectural security challenges, particularly with respect to compositing in-kernel is a bold statement that would be better supported by explaining how that research solves the security risks rather than launching an ad hominem attack against a different kernel family than I even mentioned is just a weird defensive reaction.
  - LavenderDay3544 1y ago

astrange 1y ago

A monolithic kernel and resource locators that automatically mount network drives? That's just macOS. (You don't have to recompile the kernel if you put all the device drivers in it, just keep the object files around and relink it.)

LavenderDay3544 1y ago

Incremental compilation makes that a lot less heavyweight than you would think and the idea is to automate the process so the average non-technical user doesn't need to know or care how it works.