With gdb, prints, and lots of thinking. In other words, pretty much like you'd debug one elsewhere, except instead of "run" in gdb you need "target remote <guest-gdbserver -address>".
When all of the "kernel" exists to service that single application alone, does it matter? Where does the kernel start and the application/libraries end? Who says that a protection barrier is even best suited for every application at what is typically the syscall level?
Yes, you can add protection barriers (at least if the underlying HW supports it), but I have trouble imagining what you'd really gain. Maybe, if we assume the cloud, if you restrict the hypercalls to the "kernel", you can add some extra fences an attacker would need to go through to attack the hypervisor, but that barrier would not be at the normal user/kernel separation in a general purpose OS.
how do I debug a program running on a unikernel?
With gdb, prints, and lots of thinking. In other words, pretty much like you'd debug one elsewhere, except instead of "run" in gdb you need "target remote <guest-gdbserver -address>".
if my program crashes, will it crash the unikernel? is there a usermode/kernelmode separation?
Given that unikernels are very different from one another, it depends on exactly which one.
When all of the "kernel" exists to service that single application alone, does it matter? Where does the kernel start and the application/libraries end? Who says that a protection barrier is even best suited for every application at what is typically the syscall level?
Yes, you can add protection barriers (at least if the underlying HW supports it), but I have trouble imagining what you'd really gain. Maybe, if we assume the cloud, if you restrict the hypercalls to the "kernel", you can add some extra fences an attacker would need to go through to attack the hypervisor, but that barrier would not be at the normal user/kernel separation in a general purpose OS.
This title sounds like a children's fairytale.
neat!
You beat me to this! Awesome!
Sweet, nice work.