[HN Gopher] Unikernel Linux (UKL) (2023)
___________________________________________________________________
Unikernel Linux (UKL) (2023)
Author : pabs3
Score : 95 points
Date : 2025-04-18 08:11 UTC (14 hours ago)
(HTM) web link (dl.acm.org)
(TXT) w3m dump (dl.acm.org)
| rwmj wrote:
| 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 ...
| c0wb0yc0d3r wrote:
| 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?
| rwmj wrote:
| 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.
| avsm wrote:
| 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
| rwmj wrote:
| 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.
| pjmlp wrote:
| 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.
| intelVISA wrote:
| Looks like a nice weekend project, who would actually fund this
| kind of hacking??
| rwmj wrote:
| Red Hat & Boston University were the main participants.
| pabs3 wrote:
| Have you considered talking to the German Sovereign Tech Agency
| about funding the completion and merging upstream of the
| project?
|
| https://www.sovereign.tech/
| rzzzt wrote:
| 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
| phendrenad2 wrote:
| 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.
| rwmj wrote:
| 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.
___________________________________________________________________
(page generated 2025-04-18 23:01 UTC)