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

51–60 of 187 posts

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

#51

Post by arbarb »

rwmj wrote: post #47
xfs wrote: post #40

Earlier quoted context omitted.

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?

> Is it correct to think of it as application code running as PID 1 in kernel space? getpid exists and returns a number - in fact it can return any number you like :-) Everything is linked into a single vmlinux which runs in a single address space. (As an aside I'll have to remember to ask Ali if he's thought about what number getpid() should return in UKL - I guess returning 1 would cause least surprise) > Can I for…

Slight clarification. Yes, UKL has normal kthreads, but all the application code runs using pthreads. And their implementation is unchanged, except the fact that they do function calls instead of syscall.

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

#52

Post by masklinn »

reubensutton wrote: post #8

My gut instinct is always that using traditional kernels in a unikernel way is a bit suboptimal because it doesn’t become a “library operating system” in the same way that Mirage does.

While that's true, the flip side is that "traditional" kernels have much better hardware (and general) support because they benefit from the long history of the "main project".

Stripping down traditional kernels to work as unikernels is not a new thing: https://github.com/rumpkernel/rumprun

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

#54

Post by MrBuddyCasino »

> Unikernels have demonstrated enormous advantages over Linux in many important domains

By domains, do they mean that as "actually in use in certain sectors in the industry" or "a prototype has shown that"?

> causing some to propose that the days of Linux's dominance may be coming to an end

Who exactly would make that claim?

So, besides performance: what actual, real-life problems does this solve? I think there is some overlap with containers, and at this point, replacing them will require something a lot better.

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

#55

Post by joosters »

rwmj wrote: post #2

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

What are the plans regarding multithread / multiprocess support?

On the face of it, multiprocess support might seem a bit stupid, but it would greatly help the porting of more complex applications. The 'processes' wouldn't need virtual address space or memory protection, just give them a block of memory and pick a CPU to run the code.

If you have multithreading, do you need any scheduling code, or can you just pick a CPU for each thread and leave them to run? What about the kernel's own threads & processes?

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

#57

Post by MaxBarraclough »

rwmj wrote: post #2

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

What do you make of the highly critical Assessing Unikernel Security paper [0]? Have things changed since its publication?

[0] https://www.nccgroup.trust/globalassets/our-research/us/whit... , from https://news.ycombinator.com/item?id=19738905

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

#58

Post by helldritch »

rwmj wrote: post #33
dodobirdlord wrote: post #24

Earlier quoted context omitted.

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.

For those, like me, who don't know what the acronym LTO is: it's Link-time optimisation, the stage during compilation where the "linker" has all of the object files which make up your program available to it, and is therefor able to optimise across the entire program at once (instead of the individual constituent source files which make up the program).

There's a long, detailed PDF about LTO produced by GCC which was useful in helping me to understand exactly how this works here: https://gcc.gnu.org/projects/lto/lto.pdf

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

#60

Post by rwmj »

MaxBarraclough wrote: post #57
rwmj wrote: post #2

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

What do you make of the highly critical Assessing Unikernel Security paper [0]? Have things changed since its publication? [0] https://www.nccgroup.trust/globalassets/our-research/us/whit... , from https://news.ycombinator.com/item?id=19738905

I can't read that paper. Firefox says the HSTS cert is wrong.

Edit: Thanks for the updated link. UKL can be compiled with usual hardening features like ASLR, stack hardening, RELRO.

As I said here (https://news.ycombinator.com/item?id=23202042) I'm dubious about the security story around unikernels, but most of the issues in this paper are not relevant to UKL specifically.

Post reply on HN