Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unikernels: The Next Stage of Linux’s Dominance (2019)

dl.acm.org

Post reply on HN
Print view View original

31–40 of 187 posts

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#31

Post by rwmj »

cma wrote: post #20
radicalbyte wrote: post #18

Earlier quoted context omitted.

As I've always understood it, it's not just performance but also security: there's a lot less code running with your code which cuts the surface area for bugs and thus security holes.

Wouldn't a crash or other problem in your program potentially corrupt e.g. the kernel tcp stack?

As the program and kernel run in a single address space, yes there is no separation from your application corrupting parts of the kernel.

I'm not very convinced about the security story around unikernels, but for balance the other side of the argument is that there's much less code around in a unikernel - no shell, no command line tools at all, no compilers or interpreters, just the code required to run the program and talk to the hardware (real or virtual).

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#32

Post by rwmj »

perbu wrote: post #22
tasubotadas wrote: post #3

Earlier quoted context omitted.

What is a unikernel and why it's good?

Basically you replace the system calls into the kernel with library calls. So you end up with a single binary that contains both the application as well as the operating system functionality. This can lead to some rather spectacular performance benefits. One thing is that you remove the syscall overhead, but more importantly you can do a lot more optimizations at the compiler/linking steps. You can remove complex cod…

Another performance benefit (unsurprising in highsight) comes from removing KPTI and similar Spectre mitigations. These have really made system calls in regular kernels expensive.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#33

Post by rwmj »

dodobirdlord wrote: post #24
boxed wrote: post #9

Earlier quoted context omitted.

I also don't get it. "Linux as a unikernel" does not make sense. The entire point of a unikernel is to not have the OS in every container/VM.

If you statically link your software with the kernel, presumably an optimizing compiler will be able to remove most of the kernel from the resulting binary.

Yes. Also LTO becomes possible.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#35

Post by xfs »

ncmncm wrote: post #26

When I make a system where a unikernel could do the job, I usually want a full OS for program setup and initialization, and then an isolated core for the main loop, sharing (single-writer) memory pages with other, less performance-critical processes for logging, stats reporting, and any needed file system activities. The makers of top-performing NICs have been quite good at providing direct user-space access to their…

Recently I found out ebpf jitting will cause interprocessor interrupts even with all the isolation configs available today. There's probably many more places where such interrupts could be generated and not handled by the current isolation mechanism. Not saying a unikernel is directly a solution but CPU isolation isn't perfect either and could use something from a unikernel.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#36

Post by pinopinopino »

rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

Really cool work!

Is there really a support layer for Emacs in the kernel?

Now the real question. You are statically linking against a modified glibc, so they make calls to your kernel library instead to the system call and you can do some nice optimizations along the way. Which I think make sense.

I can see this is cool for things that directly interface to glibc, but do you think this is viable for applications using multiple layers between the kernel and the application?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#37

Post by rwmj »

pinopinopino wrote: post #36
rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

Really cool work! Is there really a support layer for Emacs in the kernel? Now the real question. You are statically linking against a modified glibc, so they make calls to your kernel library instead to the system call and you can do some nice optimizations along the way. Which I think make sense. I can see this is cool for things that directly interface to glibc, but do you think this is viable for applications usi…

At the moment you must go through glibc. For example issuing SYSENTER or INT 80h will not work.

We have only run C applications so far, so I'm unsure how it will all work for servers written in other programming languages. I think applications which rely on complex multi-process middleware (like Java JBoss, etc) will be hard or even impossible to port.

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#38

Post by dathinab »

lmm wrote: post #16
perbu wrote: post #12

Unikernels are typically statically linked. Using copyleft code means the whole resulting binary is subject to copyleft. Free software is great, but not everyone is in the position where they can release all of their code all the time. For a unikernel to be viable it can't have copyleft code in it.

Depends what you're using it for. If you're just running it as a server then (non-A) GPL code is fine since you're not distributing the program.

But what about the cloud and auto scaling wouldn't that count as distribution (through for internal use only)?

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#39

Post by rwmj »

dathinab wrote: post #38
lmm wrote: post #16

Earlier quoted context omitted.

Depends what you're using it for. If you're just running it as a server then (non-A) GPL code is fine since you're not distributing the program.

But what about the cloud and auto scaling wouldn't that count as distribution (through for internal use only)?

It's an interesting point. I wonder if sending a binary to AWS counts as distribution to a third party?

(Of course I work for Red Hat and the cult thinks all code should be free :-)

Re: Unikernels: The Next Stage of Linux’s Dominance (2019)

#40

Post by xfs »

rwmj wrote: post #2

I'm one of the authors on this paper, so ask away if you have questions.

Is it correct to think of it as application code running as PID 1 in kernel space? Can I fork or create threads? Can I directly access kernel's internal APIs like a kernel module?
Post reply on HN