Neat, but you probably don't need this. Just compile a regular POSIX program and embed it into the kernel image with initramfs or initrd, or drop it alongside the kernel on the UEFI partition (if you're in a x86 environment). You might want busybox or your own init process to start up your program and monitor it.

That's true but kind of missing the point. In UKL the program is part of the kernel. The userspace (if you have one at all) is only there for debugging and performance testing. The program has direct access to the kernel internals which it runs alongside, although for most things it uses the regular syscall API and has its own glibc (also linked into the kernel).

However there are some similarities. The trust boundary is between the hardware and the unikernel (kernel + userspace in your case). If the program goes rogue / gets exploited, then networking and firewalls are what protects you. Or in the case where you run the unikernel in a VM, then it's the virtualization boundary that protects you.

Am I surprised this was downvoted? No, of course not. In this thread, about unikernels, we must limit the discussion to the narrow mindset that unikernels are a menaingful and useful abstraction. Me chiming in pointing out that they aren't, with my rationale, isn't welcome. And we wonder why Bobby can't program.