Didn't expect this one on HN. I was a supervisor for this project (past tense, sadly, as research funding dried up in the end). Ask me anything, I guess ...
They fund developers internationally, so their web presence is international, a .de would signal a more German audience. Perhaps at some point they will become funded by multiple EU countries too.
I can only read the abstract. It mentions that applications need to be recompiled. Would that mean applications when in dotnet or java wouldn’t need modification, just their runtime would?
Yes, everything has to be recompiled, because it must be linked to the Linux kernel to create a single vmlinuz containing application + kernel.
One of the aims[1] was requiring minimum source-level modifications to achieve this. For C/C++ programs this was pretty much achieved. As you say for Java or Dotnet you'd have to port the runtime (which we never did) and then the class files ought to run unmodified on top.
Having said that, there's not much benefit to this (perhaps a negligible increase in performance) if you only link your application to Linux. The real benefits come when hotspots within your application are modified so they interact directly with Linux internals (noting that Linux internal APIs are not stable). One example from the paper is shortcutting through the VFS when you know that a read(2) call is always reading from a TCP socket. Another might be to arbitrarily modify page tables to make your garbage collector more efficient. Another one which my student was working on was making Linux epoll handlers direct call into the "userspace" code that handles an event.
A cute part of this is that it's still Linux, just with a "fatter" kernel containing the application. It still has a userspace, and you can still run stuff in that userspace if you want. That's especially useful for debugging (put sshd + a shell in there), or performance analysis (run perf alongside the unikernel program).
There are definitely arguments to be had about whether any of this is a good idea or not, which is why it's a research paper. I think nowadays I'd say that much of the performance benefit can be achieved using io_uring.
[1] Another aim was making minimum changes to Linux itself so it might have some chance to go upstream, which of course it never did.
This project really should be resurrected; I'll try to find a student for this in Cambridge for the next academic cycle! I was just thinking a few days ago [1] about how a webassembly architecture for Linux brings out many of the same issues: you need to recompile apps, but then have a very flexible FFI to the outside world.
The tombl Linux-wasm [2] seems like it could be a path to upstream many of the ideas in UKML, but with a new target arch behind it so it's not just a performance boost but also a portability one. The browser demo is pretty impressive: https://linux.tombl.dev
Hi Anil, we can have a chat some time. You've got my email. However note that all the work so far was done at BU, and the students who worked on it have largely moved on to companies in the Boston area.
I feel that with the uptake in container technology, kubernetes, serverless approaches, with managed runtimes, running directly on top of type 1 hypervisors, the have kind of achieved unikernel ideas, even if not in an ideal form.
The usual worse is better outcome.
Naturally this doesn't fit the traditional C and C++ execution model, due to the expectations of a POSIX environment instead of the rich runtimes from managed languages, which is where I see the value of this kind of work.
This might be a naive question - does this approach mean that the application and the kernel is now a single binary, and thus application crashes now translate to kernel panics? I guess now that we have docker it isn’t such a big deal, but otherwise it places a lot of confidence on the robustness of the application itself.
Yes & yes. Even "worse", there's no memory protection between the application and the kernel so application bugs can and will trample over kernel structures.
The way you'd typically use this is either on isolated hardware - with a hardware watchdog to reboot it, and firewalls to protect the rest of the network - or in a VM where the trust boundary is between the guest and the hypervisor (as is true for all VMs).
Users of unikernels understand these risks / limitations, but judge that the improved performance or ability to do things beyond what is possible with the syscall API is worth it. It's definitely not for everyone.
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.
Didn't expect this one on HN. I was a supervisor for this project (past tense, sadly, as research funding dried up in the end). Ask me anything, I guess ...
Have you considered talking to the German Sovereign Tech Agency about funding the completion and merging upstream of the project?
https://www.sovereign.tech/
Begs the question, why this isn't a .de domain?
They fund developers internationally, so their web presence is international, a .de would signal a more German audience. Perhaps at some point they will become funded by multiple EU countries too.
I can only read the abstract. It mentions that applications need to be recompiled. Would that mean applications when in dotnet or java wouldn’t need modification, just their runtime would?
The full paper is here: https://dl.acm.org/doi/pdf/10.1145/3552326.3587458
Yes, everything has to be recompiled, because it must be linked to the Linux kernel to create a single vmlinuz containing application + kernel.
One of the aims[1] was requiring minimum source-level modifications to achieve this. For C/C++ programs this was pretty much achieved. As you say for Java or Dotnet you'd have to port the runtime (which we never did) and then the class files ought to run unmodified on top.
Having said that, there's not much benefit to this (perhaps a negligible increase in performance) if you only link your application to Linux. The real benefits come when hotspots within your application are modified so they interact directly with Linux internals (noting that Linux internal APIs are not stable). One example from the paper is shortcutting through the VFS when you know that a read(2) call is always reading from a TCP socket. Another might be to arbitrarily modify page tables to make your garbage collector more efficient. Another one which my student was working on was making Linux epoll handlers direct call into the "userspace" code that handles an event.
A cute part of this is that it's still Linux, just with a "fatter" kernel containing the application. It still has a userspace, and you can still run stuff in that userspace if you want. That's especially useful for debugging (put sshd + a shell in there), or performance analysis (run perf alongside the unikernel program).
There are definitely arguments to be had about whether any of this is a good idea or not, which is why it's a research paper. I think nowadays I'd say that much of the performance benefit can be achieved using io_uring.
[1] Another aim was making minimum changes to Linux itself so it might have some chance to go upstream, which of course it never did.
This project really should be resurrected; I'll try to find a student for this in Cambridge for the next academic cycle! I was just thinking a few days ago [1] about how a webassembly architecture for Linux brings out many of the same issues: you need to recompile apps, but then have a very flexible FFI to the outside world.
The tombl Linux-wasm [2] seems like it could be a path to upstream many of the ideas in UKML, but with a new target arch behind it so it's not just a performance boost but also a portability one. The browser demo is pretty impressive: https://linux.tombl.dev
[1] https://anil.recoil.org/notes/wasm-on-exotic-targets [2] https://github.com/tombl/linux
Hi Anil, we can have a chat some time. You've got my email. However note that all the work so far was done at BU, and the students who worked on it have largely moved on to companies in the Boston area.
Interesting work.
I feel that with the uptake in container technology, kubernetes, serverless approaches, with managed runtimes, running directly on top of type 1 hypervisors, the have kind of achieved unikernel ideas, even if not in an ideal form.
The usual worse is better outcome.
Naturally this doesn't fit the traditional C and C++ execution model, due to the expectations of a POSIX environment instead of the rich runtimes from managed languages, which is where I see the value of this kind of work.
This might be a naive question - does this approach mean that the application and the kernel is now a single binary, and thus application crashes now translate to kernel panics? I guess now that we have docker it isn’t such a big deal, but otherwise it places a lot of confidence on the robustness of the application itself.
Yes & yes. Even "worse", there's no memory protection between the application and the kernel so application bugs can and will trample over kernel structures.
The way you'd typically use this is either on isolated hardware - with a hardware watchdog to reboot it, and firewalls to protect the rest of the network - or in a VM where the trust boundary is between the guest and the hypervisor (as is true for all VMs).
Users of unikernels understand these risks / limitations, but judge that the improved performance or ability to do things beyond what is possible with the syscall API is worth it. It's definitely not for everyone.
Other unikernels use more typesafe languages like OCaml etc, so there is less chance of kernel panics.
Guess you just reboot after crashes, and since you are probably running Unikernels in VMs, it doesn't take very long.
Looks like a nice weekend project, who would actually fund this kind of hacking??
Red Hat & Boston University were the main participants.
The "references" section points to an LKML thread and the project's GH repo:
- https://lore.kernel.org/lkml/20221003222133.20948-1-aliraza@...
- https://github.com/unikernelLinux/ukl
[dead]
[dead]
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.