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

101–110 of 187 posts

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

#101

Post by nabla9 »

masklinn wrote: post #93
nabla9 wrote: post #75

Earlier quoted context omitted.

This is not categorically true. Linux is licensed under GPL-2.0 WITH Linux-syscall-note. >NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". More generally can link LGPL code statically without making resulting binary subject to copyleft or releasing the source co…

> This is not categorically true. GP provided a clear scenario in which their warning is categorically true. > Linux is licensed under GPL-2.0 WITH Linux-syscall-note. The note clarifies that syscalls are interpreted as a form of dynamic linking, which would be quite obvious in retrospect given you can run unmodified linux software on non-linux kernels ( https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux ). >…

> And that what you quote specifically notes that even under the LGPL, static linking results in a derived work?

No. You can provide object files without source code and it does not become covered work. This is for example how using LGPL in Qt works.

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

#102

Post by EnigmaCurry »

rectang wrote: post #95

Can a unikernel be used to create a sound/music application which is not afflicted by the latency problems which bedevil such applications when running inside traditional operating systems? For example, could it be used for a softsynth which takes in midi input and emits digital audio with the OS only contributing guaranteed sub-millisecond latency?

is that not what the linux realtime patches do? https://wiki.archlinux.org/index.php/Realtime_kernel_patchse...

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

#103

Post by rwmj »

la6471 wrote: post #94
rwmj wrote: post #2

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

Is the final vision to somehow put together a packager that will put together an application plus UK together to run on any virtual system. Maybe one can extend packer to create this binary similar to how it creates container.Also FaaS providers like AWS lambda or google functions - aren’t they already doing this?

I wouldn't say the final vision is clear yet, but what I'd like to see would look something like a "liblinux.a", and you would compile your application using your normal compiler, and link it to this library to end up with a vmlinux that would run in a VM or on baremetal.

Actually achieving this is tricky: At the moment you need to use special compiler flags and a completely different link line from normal. Then there's the issue of how/whether the library Linux is configured generically or you somehow allow people to set CONFIG_* options.

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

#104

Post by nabla9 »

masklinn wrote: post #91
nabla9 wrote: post #78

Earlier quoted context omitted.

Linux is licensed under GPL-2.0 WITH Linux-syscall-note. >NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". (even without actual syscall, you can consider unikernels as normal use of kernel)

The original comment specifically put forward the following scenario: > Unikernels are typically statically linked. The note you're quoting is about regular software performing regular syscalls which is runtime dynamic linking to the kernel (so much so that multiple OS (e.g. SmartOS, Windows) implemented linux persona which allow running unmodified Linux software against a non-linux kernel). It does not apply in a sc…

> It does not apply in a scenario where you would statically link to the kernel.

That's not the interpretation everyone else uses.

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

#105

Post by rwmj »

MichaelMoser123 wrote: post #97
rwmj wrote: post #2

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

isn't it hard to develop/debug/monitor an application with this approach? I mean you can't just run a debugger as another process and attach to the thing, you can't run tcpdump or strace, nothing of that sort. Also every bad pointer access will require a reboot, wouldn't it? I mean how do you develop an application with this approach?

All good questions without a clear answer at the moment. Bad pointers in the application can overwrite kernel data structures because everything runs in a single address space.

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

#106

Post by vbezhenar »

masklinn wrote: post #48
vbezhenar wrote: post #45

Earlier quoted context omitted.

You can write proprietary kernel drivers. Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations.

> You can write proprietary kernel drivers. IIRC you can write proprietary kernel modules , which are loaded at runtime. > Why can't you link user code with kernel? User code usually depends on POSIX interface and Linux is just one of the implementations. Because the kernel is licensed under GPLv2. If you statically link to the kernel, then all interpretations of the GPL are that your work is a derivation and must be…

So if your "userspace" payload is dynamically linked and loaded at runtime, it's no longer a problem? I don't think that there is a big performance hit for dynamic loading. Probably something like LTO won't work.

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

#107

Post by wildmusings »

MichaelMoser123 wrote: post #97
rwmj wrote: post #2

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

isn't it hard to develop/debug/monitor an application with this approach? I mean you can't just run a debugger as another process and attach to the thing, you can't run tcpdump or strace, nothing of that sort. Also every bad pointer access will require a reboot, wouldn't it? I mean how do you develop an application with this approach?

You can debug a normal kernel over the network. I imagine you can do the same with a unikernel.

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

#108

Post by heavenlyblue »

MichaelMoser123 wrote: post #97
rwmj wrote: post #2

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

isn't it hard to develop/debug/monitor an application with this approach? I mean you can't just run a debugger as another process and attach to the thing, you can't run tcpdump or strace, nothing of that sort. Also every bad pointer access will require a reboot, wouldn't it? I mean how do you develop an application with this approach?

> Also every bad pointer access will require a reboot, wouldn't it?

Hm, isn’t reboot just slightly more complicated than restarting your application? And most of the today’s apps would still require “rebooting” be it a container or a virtual machine

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

#109

Post by heavenlyblue »

rwmj wrote: post #31
cma wrote: post #20

Earlier quoted context omitted.

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 a…

Wouldn’t directly linking system calls make every address space more unique and thus make it harder to write (generic) exploits for?

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

#110

Post by heavenlyblue »

axegon_ wrote: post #27

Full disclosure: I have only briefly fiddled with unikernels. And in all honesty, I think there could be a good real life application for them. But the biggest problems I see is that even though they have been around for a while, building them is still incredibly complex and time consuming and there isn't a core community behind them and looking at it, it seems like they are starting to suffer from the javascript syn…

Isn’t that’s what this whole thread about? Making it easier by providing Linux as a compilation target.
Post reply on HN