
ProcOS: scheduling atop Unikernels - akkartik
https://bentrask.com/?q=hash://sha256/50ba5e38a149a2a6972e1dd1cc2215ea4d07e64fb980edabc692052c626aa43f
======
eriknstr
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
Actually that's more interesting than not-really-unikernel thing he was
thinking about.

------
jlg23
> 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).

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

~~~
glandium
hypervisor+unikernels do sound a lot like microkernel+processes...

~~~
ori_b
Unikernels are processes with a really funny system call ABI.

~~~
rwmj
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.

------
graycoder
Is this effectively describing what an init does?

~~~
yellowapple
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.

------
jopsen
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
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.

------
monocasa
Sounds like exokernels.

