mvaralar

Feel free to submit a PR I will happily accept it.

Toro started in 2006 more or less. I lost the .org domain so I had to move to the .io.

As far as you provide the bindings, you can compile it with an application built in any language. There are in the repo a few examples with C programs.

> Both those "separations" is not something Toro provides on its own; the Toro unikernel would totally be under the control of the host, from what I can tell. That said, what Toro (or any unikernel, really) does is reduce the attack surface area, as the (guest) supervisor is pruned to run just one particular application (more code to partition things up will eliminate a class of attacks but may result in new attack vectors [2]).

Toro does not provides that separation. However, I was having some thoughs about running the user app in ring1 to provide some sort of separation whereas the kernel runs in ring0. However, in that case, we may end up in the current user/kernel level separation of general purpose OSs.

I can add that. Thanks!

Toro is just a library OS that allows you to build an application and deploy it as a VM without the OS. Toro acts as the OS. Different that other unikernels, Toro is not meant to be POSIX compliant. The idea is to provide an API that suits better the use-case, i.e., an app deployed as a VM. Toro can also run in baremetal although I dropped the support a few commits ago. I can roll back that support in case there is interest.

> Suppose you control the entire stack though, from the bare metal up. (Correct me if I'm wrong, but) Toro doesn't seem to run on real hardware, you have to run it atop QEMU or Firecracker. In that case, what difference does it make if your application makes I/O requests through paravirtualized interfaces of the hypervisor or talks directly to the host via system calls? Both ultimately lead to the host OS servicing the request. There isn't any notable difference between the kernel/hypervisor and the user/kernel boundary in modern processors either; most of the time, privilege escalations come from errors in the software running in the privileged modes of the processor.

Toro can run on baremetal although I stopped to support on that a few years ago. I tagged in master the commit when this happened. Also, I removed the TCP/IP Stack in favor to VSOCK. Those changes, though, could be reversed in case there is interest on those features.