For those who don't want to read the whole paper, I'd made a short ten minute explainedy video going through it:
Unikernels: The Next Stage of Linux's Dominance [pdf]
61–70 of 104 posts
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#62all 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…
I was actually planning a Unikernel based deployment of Memcached (OSv) as a L2 cache for our application servers. I thought that user/kernel separation didn’t matter that much when only a single application is ran in a microkernel, and the data exfiltration risk would be the same as if we were running it on a typical Linux box.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#63all 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…
If you read that article, they tested two unikernels and the key point was that unikernels don't implement security mechanisms present in a normal OS. This Linux Unikernel, otoh, does not delete any of that security functionality. The boot up code is the same, it just calls a specific code instead of bringing up the general userspace. Unikernels and security don't have to be mutually exclusive.
I wonder if there's a specific unikernel linux kernel that we can "diff -u /usr/src/foo /usr/src/bar > gimme_dat.patch" against its upstream.
I'd love to see if we could get some KSPP/hardened/etc-derived unikernels.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#64all 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…
We literally just talked about this in a video done yesterday for application security weekly - https://www.youtube.com/watch?v=Hob1iLjIgWE - I previously wrote my thoughts on it here as well:
https://nanovms.com/dev/tutorials/assessing-unikernel-securi...
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#65Long 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…
>Why not go all the way, and work into the ALU and remove the bits you don't need? And then go into the micro code, and the associated FPGA, and everything else..
Because there are diminishing returns...
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#66> Unikernels have demonstrated enormous advantages over Linux in many important domains, causing some to propose that the days of Linux's dominance may be coming to an end. Where are unikernels widely used?
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…
You still retain all of the hypervisor monitoring and tuning tools. And you can tune the unikernel using different build options. Debugging is probably not as fleshed out, but it does not seem to be an impossible task.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#67Earlier quoted context omitted.
Yes. And its almost impossible to do this without a huge investment in time and effort, except: If you use languages with FP, and are rigorous, then I believe (possibly wrongly) its actually somewhat simpler to understand because the style of coding in FP exposes much of this "better" than in classic imperative coding So yes, I think you're right: great dream, hugely hard to do, if not actually impossible in most cas…
I think it's impossible, or close to it. Isn't it just another form of the halting problem? https://en.wikipedia.org/wiki/Halting_problem
Well, the alternative is that you limit the set of things you can do, such that you no longer have a Turing machine. But that's certainly less fun, isn't it?
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#68Can anyone commnent on how this approach differs from LinuxKit? Or is the LinuxKit plan at all unikernel (MirageOS) based anymore? I hope people will only use unikernels with memory-safe languages or otherwise well sandboxed runtimes.
It's worth noting that Linux itself is written in C (not rust).
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#69The article is Tl;Wbmloc;Dr (too long, way beyond my level of comprehension, didn't read), so forgive any stupid questions. Could the unikernel technology be used to build extremely small Linux distros that contain just the bare minimum to satisfy all dependencies for running say a single software or a small group of them. I'm not interested in virtual machines for network related services but rather in small embedde…
Alpine Linux is a reasonably small (20mb) Linux distribution, I've seen it run on bare metal but it's more common to see it in Docker environments. Building minimal bootable to be very small is possible, but is difficult in comparison to an apt install - I imagine for the most part porting docker container configs to a bootable OS might be the best approach for small-medium projects.
This is brought up quite a lot and isn't answered correctly enough in my opinion.
The problem with this approach is that you can make it as small as you want but it's still Linux. At a certain point are you going to start patching things out like support for users? Support for management of multiple processes? There's a non-trivial set of syscalls and data structures designed solely for these constructs. You can't just seccomp it and call it a day.
For us it's not about the size (that's nice of course) but it's more about the performance and security.
Re: Unikernels: The Next Stage of Linux's Dominance [pdf]
#70This is a paid article. Am I missing something?
I'm getting this link:
https://dl.acm.org/citation.cfm?id=3321445
The link the PDF contains IDs and stuff which differ each time I visit, which seems unnecessary.
Maybe get it from here: https://www.reddit.com/r/programming/comments/cb17mn/read_a_...
which links to: https://www.cs.bu.edu/~jappavoo/Resources/Papers/unikernel-h...