4 ms·

ProcOS: scheduling atop Unikernels

53 points by akkartik 9y ago

graycoder 9y ago
Is this effectively describing what an init does?
- yellowapple 9y ago
  I think the key difference here is that the "init" is actually the process scheduler, and each of those managed processes is actually an "init" for its own children, and so on. Kind of like running a VM inside of a VM inside of a VM inside of a VM, but with less VM-specific baggage and more process-related baggage.
- efficax 9y ago
  Except that you'd have, to example, run the network stack as a process. What he's describing is closer to a microkernel than anything.
- zodiac 9y ago
  No, init still relies on the OS scheduler to switch between it and each of its child threads
dkarapetyan 9y ago
Kinda misses the point of unikernels. The hypervisor already does all the necessary scheduling. You don't need another scheduler.
- glandium 9y ago
  hypervisor+unikernels do sound a lot like microkernel+processes...
  - ori_b 9y ago
    Unikernels are processes with a really funny system call ABI.
    - rwmj 9y ago
      If you run them in qemu then this becomes very clear. Even better (or worse?) the strange system call ABI is translated into regular system calls by the qemu process.
  - justincormack 9y ago
    Hypervisors are often microkernels, eg Xen is. Obviously KVM isn't as it's Linux...
- btrask 9y ago
  I think a unikernel+ProcOS is basically the same as a hypervisor+unikernel, except backwards. The main advantages would be less overhead (one unikernel, instead of N) and greater flexibility (because ProcOS can run on any OS without a VM). The emphasis on cheap recursion (if it can be achieved) also has benefits like making administrative responsibilities easier to delegate, and preventing various isolation leaks (including scheduling fairness).
jopsen 9y ago
How is it different from a microkernel? Randomly, I think the interesting thing with unikernels is that with most modern languages being memory-safe (rust, python, java, .net, javascript) we don't need process isolation.
- muricula 9y ago
  A micro kernel runs drivers in userland and has a "micro" ring 0 footprint. A unikernal bundles only the necessary drivers into an OS which runs only one process and basically pushes multiprocess support into the hypervisor. His idea isn't yet fully baked, but it's basically having a userland os provide scheduling and permissions management for other os's on the machine. Which is a little odd because the hypervisor needs its own scheduler to decide what vm to run next, and switching from a vm, to the hypervisor, to the scheduler vm, to the hypervisor, to another vm sounds really inefficient. Why not have the scheduler in the hypervisor? Having a dedicated vm for permissions management sounds suspect as well, as you have to perform that same series of switches to decide whether a user is authenticated. I think what he really wants is actually a hypervisor. In a unikernel the hypervisor provides the memory isolation instead of the os. If we don't provide memory isolation at all it would basically transform remote code execution vulnerabilities into root privilege execution. If I can find a bug in your code or the cpython runtime I can own your machine. Memory safety is just the beginning of security, not a cure all.
- deleted 9y ago
  [deleted]
monocasa 9y ago
Sounds like exokernels.
monocasa 9y ago
Sounds like exokernels.
eriknstr 9y ago
Off topic but the hash shown piqued my interest. The source is linked from the page - https://github.com/btrask/stronglink https://github.com/btrask/stronglink > A searchable, syncable, content-addressable notetaking system
- Quequau 9y ago
  Actually that's more interesting than not-really-unikernel thing he was thinking about.
jlg23 9y ago
> Ultimately, how practical is this idea? Well, if you were to build a secure multiplexer, this is probably the way you’d want to build it, so that it could be as simple (meaning reliable) and versatile as possible. If I were to build a secure multiplexer as a unikernel, I'd still have the "configuration" at compile time only and I'd better have a damn good excuse to keep more state than the packet in transit on that instance (because someone would have to pay for the work to make the whole system consistent in the presence of buffering/caching nodes).

53 points by akkartik 9y ago

graycoder 9y ago

Is this effectively describing what an init does?

yellowapple 9y ago
I think the key difference here is that the "init" is actually the process scheduler, and each of those managed processes is actually an "init" for its own children, and so on. Kind of like running a VM inside of a VM inside of a VM inside of a VM, but with less VM-specific baggage and more process-related baggage.
efficax 9y ago
Except that you'd have, to example, run the network stack as a process. What he's describing is closer to a microkernel than anything.
zodiac 9y ago
No, init still relies on the OS scheduler to switch between it and each of its child threads

dkarapetyan 9y ago

Kinda misses the point of unikernels. The hypervisor already does all the necessary scheduling. You don't need another scheduler.

glandium 9y ago
hypervisor+unikernels do sound a lot like microkernel+processes...
- ori_b 9y ago
  Unikernels are processes with a really funny system call ABI.
  - rwmj 9y ago
    If you run them in qemu then this becomes very clear. Even better (or worse?) the strange system call ABI is translated into regular system calls by the qemu process.
- justincormack 9y ago
  Hypervisors are often microkernels, eg Xen is. Obviously KVM isn't as it's Linux...
btrask 9y ago
I think a unikernel+ProcOS is basically the same as a hypervisor+unikernel, except backwards. The main advantages would be less overhead (one unikernel, instead of N) and greater flexibility (because ProcOS can run on any OS without a VM). The emphasis on cheap recursion (if it can be achieved) also has benefits like making administrative responsibilities easier to delegate, and preventing various isolation leaks (including scheduling fairness).

jopsen 9y ago

How is it different from a microkernel? Randomly, I think the interesting thing with unikernels is that with most modern languages being memory-safe (rust, python, java, .net, javascript) we don't need process isolation.

muricula 9y ago
A micro kernel runs drivers in userland and has a "micro" ring 0 footprint. A unikernal bundles only the necessary drivers into an OS which runs only one process and basically pushes multiprocess support into the hypervisor. His idea isn't yet fully baked, but it's basically having a userland os provide scheduling and permissions management for other os's on the machine. Which is a little odd because the hypervisor needs its own scheduler to decide what vm to run next, and switching from a vm, to the hypervisor, to the scheduler vm, to the hypervisor, to another vm sounds really inefficient. Why not have the scheduler in the hypervisor? Having a dedicated vm for permissions management sounds suspect as well, as you have to perform that same series of switches to decide whether a user is authenticated. I think what he really wants is actually a hypervisor. In a unikernel the hypervisor provides the memory isolation instead of the os. If we don't provide memory isolation at all it would basically transform remote code execution vulnerabilities into root privilege execution. If I can find a bug in your code or the cpython runtime I can own your machine. Memory safety is just the beginning of security, not a cure all.
deleted 9y ago
[deleted]

monocasa 9y ago

Sounds like exokernels.

monocasa 9y ago

Sounds like exokernels.

eriknstr 9y ago

Off topic but the hash shown piqued my interest. The source is linked from the page - https://github.com/btrask/stronglink https://github.com/btrask/stronglink > A searchable, syncable, content-addressable notetaking system

Quequau 9y ago
Actually that's more interesting than not-really-unikernel thing he was thinking about.

jlg23 9y ago

> Ultimately, how practical is this idea? Well, if you were to build a secure multiplexer, this is probably the way you’d want to build it, so that it could be as simple (meaning reliable) and versatile as possible. If I were to build a secure multiplexer as a unikernel, I'd still have the "configuration" at compile time only and I'd better have a damn good excuse to keep more state than the packet in transit on that instance (because someone would have to pay for the work to make the whole system consistent in the presence of buffering/caching nodes).