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

Unikernels: The Next Stage of Linux's Dominance [pdf]

cs.bu.edu

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#81

Post by ori_b »

mirceal wrote: post #41
c0l0 wrote: post #9

Earlier quoted context omitted.

I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp)…

> Tooling/Perf/etc is not needed when running (do you really want to debug in production)

Do I want to debug in production? No.

Do I have to do it anyways? All the fucking time. I'm not perfect, I sometimes ship bugs, and when they show up in production, I need to diagnose, determine if rolling back will solve them, or whether I need to fix forward and how. Not being able to debug in production is simply unacceptable.

I want to ship perfect code. But I don't. So, instead, I debug. If the issue shows up in production, I debug in production.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#82

Post by mirceal »

ori_b wrote: post #81
mirceal wrote: post #41

Earlier quoted context omitted.

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp)…

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) Do I want to debug in production? No. Do I have to do it anyways? All the fucking time. I'm not perfect, I sometimes ship bugs, and when they show up in production, I need to diagnose, determine if rolling back will solve them, or whether I need to fix forward and how. Not being able to debug in production is simply unacceptable…

yeah no. you don’t debug in production. you have logs and metrics. if you need to debug (as in attaching the debugger) you already are in trouble

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#83

Post by ori_b »

mirceal wrote: post #82
ori_b wrote: post #81

Earlier quoted context omitted.

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) Do I want to debug in production? No. Do I have to do it anyways? All the fucking time. I'm not perfect, I sometimes ship bugs, and when they show up in production, I need to diagnose, determine if rolling back will solve them, or whether I need to fix forward and how. Not being able to debug in production is simply unacceptable…

yeah no. you don’t debug in production. you have logs and metrics. if you need to debug (as in attaching the debugger) you already are in trouble

Of course I'm in already in trouble. That's why I'm debugging. I tend not to debug things that are working perfectly.

If I can't attach a profiler to find, for example, the code that contains a regex that's doing too much backtracking with production data, then I'm dead in the water. If I can't get a sample out of a system that's received a query of death, then I'm dead in the water. If I can't attach dtrace (or the equivalent) and get stats on how much I/O a system is doing in response to various events, I'm dead in the water.

Being able to dive into the depths of a system is the #1 criteria for confidently being able to put it into production.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#84

Post by danielparks »

mirceal wrote: post #41
c0l0 wrote: post #9

Earlier quoted context omitted.

I don't think that this statement describes the reality we live in. To me, unikernels feel quite a bit like statically linked server binaries running under an unprivileged UID - but you're choosing not to trust Linux' (or any other kernel's) user separation facilities, but your hypervisor's domU separation facilities instead. In exchange, you lose virtually all of your existing OS's amazing debugging and performance…

i think this kindof misses the mark. A unikernel is both the kernel (just the things you need) + app together. It’s build for one thing: whatever the app is doing. Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development. Why consider unikernels? 1) they’re stupid fast. You have only the things you need (booting in nanoseconds? yepp)…

> Tooling/Perf/etc is not needed when running (do you really want to debug in production) but tooling can be used in the process of development.

I don’t follow. Are you saying that development should build normal user space binaries, and you should only build the unikernel for production?

You will inevitably run into a behavior difference between the unikernel and user space outputs. Even if you’re not debugging in production (shudder) you need to be able to debug the unikernel.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#85

Post by weberc2 »

imbriaco wrote: post #78
weberc2 wrote: post #55

Earlier quoted context omitted.

You're moving the goal posts and invoking a straw man. No one is advocating for "pretending", and the anti-unikernel argument is that the inherent cost of unikernels in general is the loss of kernel debugging tools; not simply that "right now the unikernel debugging experience is subpar".

No, I'm not moving any goal posts. I was reacting to the statement "Tooling/Perf/etc is not needed when running". I'm not sure where you'd get the idea that I'm anti-unikernel, I just wanted to not disregard that challenge since it does matter.

I took care not to say that you were anti-unikernel; I was articulating the anti-unikernel position. I'm not sure what you actually meant, so I'll take you at your word that you weren't moving goal posts--in whatever case, the OP is correct that unikernels aren't inherently less debugable even though mature debug tooling may not exist for them today.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#86

Post by dang »

rwmj wrote: post #21

Oh, it's a paper I am (rather peripherally) involved with. If you have questions then ask away, although it's possible I might not have all the answers ... Edit: In case you can't read the paper there's a copy here: https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h... (Thanks anonymousDan in the comments below for linking to it)

We changed the URL to that from https://dl.acm.org/citation.cfm?id=3321445. Thanks!

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#87

Post by kazinator »

ggm wrote: post #49

Long ago, an OS I worked inside had a tool which took shared library indirect calls, and wired them out so you did not have a nested indirect function call cost, but went direct from the call to the backend without the pass-through the null function mapping into the specific .so library. It made things faster by one layer of the onion skin. Strip, as a UNIX tool removes the textual crap in a debuggable binary, to lea…

There is a lazy binding optimization in ELF shared libraries on GNU/Linux. The first call to the "PLT stub" of a shared library routine will self-modify so that the next call will go directly to the destination without having to calculate it again from the global offset table.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#88

Post by dwheeler »

This is really cool, though it looks like the security impact is nuanced.

Unikernel plus: A lot of code, including code with vulnerabilities, can disappear. So some vulnerabilities disappear.

Unikernel minus: The unikernel and application don't have any security isolation, since the kernel is essentially linked into the appl. As a result, the application has all the privileges of its virtual machine (not the subset that would normally be imposed by the kernel), which would normally be more privileges than it really needs. So any remaining vulnerabilities can have a more devastating effect.

That trade-off in terms of security is really hard to evaluate.

But the kinds of performance improvement shown here, with relatively modest changes, is a really really big deal. So I'd expect a lot of people to investigate this further; it certainly seems promising.

Re: Unikernels: The Next Stage of Linux's Dominance [pdf]

#90

Post by MaxBarraclough »

vectorEQ wrote: post #53

all unikernels so far suck ALOT regarding security. wouldn't recommend any of them to run in any production environment unless you want to lose all of your data. NCC group did a good article on unikernels and how crap they are if you want to know. A better idea, like already suggested would be to create an OS which builds itself according to a target application and system, to host that application on said system spe…

Here are the mandatory links to the NCC whitepaper [0], and HN discussion [1]

[0] (large PDF) https://www.nccgroup.trust/globalassets/our-research/us/whit...

[1] https://news.ycombinator.com/item?id=20507283

Post reply on HN