Go Running on the Rumprun Unikernel

#1

Post by deferpanic » Fri, Dec 11, 2015, 5:50 PM UTC

Go Running on the Rumprun Unikernel
github.com

Re: Go Running on the Rumprun Unikernel

#2

Post by billconan » Fri, Dec 11, 2015, 6:48 PM UTC

how do I debug a program running on a unikernel?

Re: Go Running on the Rumprun Unikernel

#3

Post by anttiok » Fri, Dec 11, 2015, 6:57 PM UTC

billconan wrote: post #2

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

Re: Go Running on the Rumprun Unikernel

#4

Post by billconan » Fri, Dec 11, 2015, 7:09 PM UTC

anttiok wrote: post #3

billconan wrote: post #2

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

if my program crashes, will it crash the unikernel? is there a usermode/kernelmode separation?

Re: Go Running on the Rumprun Unikernel

#5

Post by steveklabnik » Fri, Dec 11, 2015, 7:16 PM UTC

billconan wrote: post #4

anttiok wrote: post #3

Earlier quoted context omitted.

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

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.

Re: Go Running on the Rumprun Unikernel

#6

Post by anttiok » Fri, Dec 11, 2015, 7:30 PM UTC

billconan wrote: post #4

anttiok wrote: post #3

Earlier quoted context omitted.

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

if my program crashes, will it crash the unikernel? is there a usermode/kernelmode separation?

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.