This whole movement seems strange to me. It's like these are statically linking the entire OS to run a single app. Why not ditch the OS completely? I'd say this is taking the whole container concept a bit far, but who knows what will come next!
Gone Full Unikernel
81–90 of 98 posts
Re: Gone Full Unikernel
#82This whole movement seems strange to me. It's like these are statically linking the entire OS to run a single app. Why not ditch the OS completely? I'd say this is taking the whole container concept a bit far, but who knows what will come next!
If I'm not mistaken, the whole idea _is_ to ditch the OS completely. To avoid a fully functioning kernel with lots of juicy device drivers to exploit, code intended to work on systems your app will never need to worry about running on, and layers upon layers of abstraction ready and waiting to be exploited (e.g. shells).
One reason MirageOS uses OCaml, for instance, is for its memory safety properties. A truly staggering amount of vulnerabilities (e.g. Heartbleed) are due to abusing unintended ways of accessing memory in programs which face the public Internet. Since we've proven over and over again at this point that we can't reliably write safe C code, there's a reason folks are interested in eliminating as much of it as possible, all the way down to the hypervisor level. Since so many devices will be Internet-connected soon, having a way to write apps without even a possibility of "Oops" bugs like this is even more critical.
Re: Gone Full Unikernel
#83I can't help but think this is just a severe reaction to the tire fire that most Linux distros are, especially RedHat/CentOS and Ubuntu. BSD or Alpine Linux get in the way a lot less, are much more customization and compact, and have a smaller attack surface while still catering to production operations where you can run shells, profiling, logging, etc inside the execution environment.
There's more to unikernels than just being another virtualization technology. Most of the conversation on HN (as well as the content of this article) seems centered around unikernels vs. containers vs. a traditional OS in a VM, etc. But that conversation sort of misses the point. Rather than just being a competing virtualization solution, "Unikernels" are really about eschewing the existing OS paradigm altogether. Fo…
The Mirage folks didn't discover anything new in that regard.
It is how the safe OS from Burroughs, DEC, Xerox Parc, ETHZ and many others used to work.
Those OSes were written in strong typed systems programming languages, the whole stack.
Part of their security was based on the language type system.
Re: Gone Full Unikernel
#84Earlier quoted context omitted.
There is nothing stopping people from creating a unikernel for a dynamic language that also includes the development tools. A Lisp Machine on Xen would be one model.
I feel like Erlang-based unikernels are an extremely compelling alternative to traditional UNIX deployments. Immutable systems with safe hot swap and excellent debugging tools like `observer` and `debugger`.
Re: Gone Full Unikernel
#85Earlier quoted context omitted.
> Can Android be dockerized? Why? Aren't Android apps already sufficiently sandboxed?
They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM.
> They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM.
Wasn't Dalvik deprecated & replaced by ART (Andriod Runtime)? ART compiles apps AoT - IIRC; upon installation pre-Marshmallow, and while charging/idle Marshmallow going forward
Re: Gone Full Unikernel
#86Earlier quoted context omitted.
They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM.
> They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM. Wasn't Dalvik deprecated & replaced by ART (Andriod Runtime)? ART compiles apps AoT - IIRC; upon installation pre-Marshmallow, and while charging/idle Marshmallow going forward
Yep, hence me specifying the old one. ART cleans up a lot of things: no more 8-16KB main thread stacks, better code gen via AoT, fully precise collection, moving GC. It has some really ingenious features as well, like switching to a compacting GC with better throughput and space efficiency when an app goes in the background and latency is irrelevant. The switch to ART as default was actually in 5.0 (Lollipop).
It's almost enough to make me stop cursing Android developers and their children's children. Unfortunately version updates for non-Google devices are rare and everybody is still stuck supporting the majority of devices that are pre-Lollipop. Also it didn't make the APIs any better >:(
Re: Gone Full Unikernel
#87Earlier quoted context omitted.
> I understand that there currently isn't a target for Docker so that takes Google Cloud out of the equation. Google Compute Engine runs a lot more than just Docker images. It allows you to run arbitrary x86 VMs, just like EC2. It is not based on Xen, however (it is a combination of KVM and a non-QEMU VMM about which I wish I could say a whole lot more, but I don't think we're prepared to do that just now).
Right I believe that GCE is docker but it runs in a KVM container, I'm not sure why they do that however. Maybe someone else can explain? My guess would be that its a hedge on container security. However what they hand you is a docker container I believe so provided there's docker target for whatever rump kernel it should theoretically just work. No? It sounds like you work on GCE?
GCE is just plain old VMs, no Docker involved.
There's also GKE which is managed Kubernetes complete with Docker containers.
(And yes, I work on the virtual machine monitor backing GCE)
Re: Gone Full Unikernel
#88It seems this article gleefully admits many of the downsides of unikernels mentioned in https://www.joyent.com/blog/unikernels-are-unfit-for-product... , while being very brief and naive about the upsides (mainly the very contested security argument). I admittedly haven't studied the whole unikernel space yet, but intuitively they do seem unfit for production unless we spend a decade rebuilding tooling (debuggers, pr…
I wouldn't say that unikernels were entirely undebuggable. I spent a few hours hacking and came up with a proof of concept dom0 profiler, and learned some debugging benefits: one symbol table for the entire binary, one place to turn on frame pointers for everything, etc. http://www.brendangregg.com/blog/2016-01-27/unikernel-profil...
To counter the OP, you'd have to use an existing profiler.
Re: Gone Full Unikernel
#89"Nowadays very few developers interact with actual real hardware - it’s been completely abstracted away."
And i think this is a very big problem, for them its some magic pizza box, and complaint when things don't perform the way they expect it to be.
Good read though thanks!
Re: Gone Full Unikernel
#90Earlier quoted context omitted.
A microkernel could go into the kilobyte range too. seL4 is definitely in that range. The smallest Linux kernel bzImage that I ever compiled was something like 570KB, so embedded Linux might be able to reach that range too. That would of course include an application. The QNX demo likely could reach such sizes too if most of the things in it were removed. For those that are unaware, QNX is a microkernel based system.
seL4 doesn't provide very much to the programs, does it? I think it closer in spirit to Xen than to the linux kernel?
The Xen hypervisor uses a microkernel architecture. A kernel could implement a userland (e.g. traditional UNIX), a VM interface (e.g. KVM) or nothing at all (e.g. a unikernel). My point is that unikernels do not have a monopoly on small sizes and they are not worth mentioning as an advantage.