[HN Gopher] What Is Vsock and Why Use It with Unikernels?
___________________________________________________________________
What Is Vsock and Why Use It with Unikernels?
Author : eyberg
Score : 20 points
Date : 2023-07-07 17:04 UTC (1 days ago)
(HTM) web link (nanovms.com)
(TXT) w3m dump (nanovms.com)
| EdSchouten wrote:
| First we run everything as processes on top of an OS kernel. On
| UNIX, we have all of these high-level concepts of letting
| processes interact with each other. Files, pipes,
| streaming/datagram UNIX sockets, etc.
|
| Later on certain people started to see that these high-level
| concepts are bad. Operating systems are insecure. Context
| switching has overhead. Page table handling is expensive. So
| unikernels are invented.
|
| People later discover that unikernels are somewhat hard to work
| with, as the only way they can talk to the outside world is
| through virtio-like devices:
|
| - Unikernels aren't capable of just writing something to a simple
| file. No, they must write to a raw block device. Hey, that's
| annoying. Let's bring back support for native file access using
| virtio-fs! https://www.qemu.org/2020/11/04/osv-virtio-fs/
|
| - Unikernels are also not capable of simply streaming data to
| another application. No, they must include their own
| Ethernet/IP/TCP stack, and on the host system you must set up a
| network bridge (hopefully with a firewall) just to let a couple
| of unikernels talk to each other. So let's solve that using
| AF_VSOCK!
|
| At what point do unikernels become indistinguishable from
| ordinary processes running on top of an OS kernel in terms of
| features/behaviour, but reinvented poorly? I have the feeling
| that we're coming full circle at this point.
| Veserv wrote:
| The general thrust of your argument is correct, but you missed
| a key part of the evolution.
|
| People see that the operating system is insecure, so they run
| the operating system as a virtual machine on top of a
| hypervisor. The hypervisor operates the system as a bundle of
| virtual machines and provides shared services to them. People
| realize the hypervisor is just a operating system, so they
| target the hypervisor API instead of the kernel API and thus
| unikernels are invented.
|
| The question then becomes: Why unikernel on a hypervisor
| instead of a process on a operating system?
|
| The standard answer is that hypervisors are more "secure".
| However, this is total nonsense. Any technique that made a
| hypervisor "secure" could be directly applied back to a normal
| operating system as they are solving the same fundamental
| problem of multiplexing a single machine to run multiple
| programs.
|
| To quote Theo de Raadt: "You are absolutely deluded, if not
| stupid, if you think that a worldwide collection of software
| engineers who can't write operating systems or applications
| without security holes, can then turn around and suddenly write
| virtualization layers without security holes."
|
| The actual answer is that everybody sucks at multiplexing
| hardware, so everybody knows the old stuff does not work.
| However, they do not know the new stuff does not work yet, so
| they bet it all on the new stuff. Unikernels on a hypervisor
| are a strictly inferior solution to a process on a operating
| system, but people think hypervisors are better than operating
| systems, so they develop unikernels. The truth of the matter is
| that you just need a better operating system so you can develop
| processes which is a strictly better model.
| intelVISA wrote:
| Ah yes, processes on an OS: the original unikernels run by
| VMM.
|
| What next, perhaps, a VMM for VMMs? a VMMM?
| arush15june wrote:
| That's why I like the modular approach by Unikraft where the
| value is you can select which high level abstractions and
| libraries you want baked in the OS (including your application)
| [1].
|
| Compared to other unikernels designs where the OS layer is
| minimal but mostly fixed.
|
| [1] https://www.linux.com/wp-
| content/uploads/2021/02/unikraft1.p...
| eyberg wrote:
| There is a basic assumption that these applications are being
| deployed to the cloud such as AWS, GCP, Azure, etc. so your app
| is already using all of this regardless - you just don't manage
| it - the cloud vendors do.
|
| Unikernels ask the very pointed question - if we're already
| being deployed as virtual machines and using these abstractions
| why not get rid of everything else and pick up the security,
| performance, etc.
| cperciva wrote:
| I'm grown increasingly dubious of unikernels; cutting out a layer
| of indirection by running the target process in kernel space
| seemed like a good idea -- as long as you didn't need, you know,
| multiple processes -- but it looks like the performance gains
| just aren't there.
|
| _Unikernels can boot incredibly fast. Compared to a normal
| virtual machine that can take seconds to boot unikernels can boot
| in 50ms_ (quote from a white paper on the nanovms website)
|
| Considering that unikernels, by definition, don't have any
| userland, you really need to compare the unikernel boot time to
| the "time to reach init" boot time on a traditional OS -- which
| is under 100 ms with a Linux kernel, and down to 20 ms with
| FreeBSD now. A unikernel boot time of 50 ms really isn't anything
| special.
| KRAKRISMOTT wrote:
| They are great for scale to zero use cases (cloud hosting
| serverless firecrackers). With KVM rapid booting you want to
| remove as much overhead as possible, it keeps things cheap. The
| ultimate endgame would be to have a cold-start time almost
| equivalent to a prewarmed in-memory image using current
| technology. Of course, this is just one contender among many
| similar tech. If WebAssembly truly takes off, then unikernels
| would become irrelevant.
| eyberg wrote:
| Wasm and unikernels are more complimentary than competitive.
| You could actually run wasm in something like wasmer or
| wasmtime wrapped inside Nanos wrapped inside Firecracker if
| you wanted to.
|
| I think as you point out where wasm can shine are the
| function-as-a-service platforms, although the memory safety
| issues would probably need to be addressed at some point
| (writing to 0x0, no ro mem, etc.).
| KRAKRISMOTT wrote:
| The thing is Wasm already provides sandboxing, so you don't
| really need any additional KVM sandboxing, unless your
| hostile code threat model goes beyond even what typical
| cloud providers face. The Linux host for most wasm
| environments is only a single instance, often already
| running on bare metal, so there is no significant benefit
| to stripping it down to a unikernel.
| eyberg wrote:
| There are definitely other projects that are <10ms but I'm not
| convinced that a fast boot time is something worth spending a
| ton of time on. Many languages and frameworks take seconds to
| boot regardless (jvm, python ml frameworks, rails, etc.)
|
| I'll also say that if you are setting up your own bridge and
| using something like dhcp nanos actually boots faster than the
| response can come in sometimes so there' s a flag you have to
| set. I think the 'fast boot time' usecases are a relatively
| small set.
|
| Having said that there are many many other performance
| considerations besides fast boot time such as throughput, or
| request/second or random io read/writes/etc.
|
| Many web languages are single-process/single thread (eg: all
| interpreted ones) and since that is the vast majority of our
| users it isn't a problem. Threads are great if you have access
| to them and if not you scale horizontally (just like the
| interpreters do today). Multiple processes as an architectural
| design outside of scaling (and numerous issues when it actually
| does come to scaling) is something the industry really needs to
| reckon with.
| rwmj wrote:
| "Not all Unikernels". UKL is Linux and has a userland if you
| want to use it. https://github.com/unikernelLinux/ukl And it
| supports vsock already. I don't need to check because it's just
| Linux so it supports everything Linux supports.
| sacnoradhq wrote:
| Unikernels are the emperor's new clothes: they lack the stack
| of services and capabilities delivered to normal system images
| necessary for real production use: firewalls, security,
| monitoring, performance measurement, backup, auditing, and fs
| ACLs. To skip them is to put blinders on and walk around
| without clothes on.
| eyberg wrote:
| * firewalls - nanos.org is a go unikernel running on GCP and
| we punch holes for it to talk on https
|
| * security - nanos supports much of the same security you'll
| see on linux but provides more: aslr, no stack/heap exec,
| rodata no exec, text no write, no null mapping; virtio-rng
| (for some clouds where it is supported - not everywhere it
| is), pledge, unveil, honestly - there's a lot here
|
| * monitoring - plenty of apm vendors work out of the box but
| also things like cloudwatch, and our own custom service as
| well
|
| * performance measurement - we have things like ftrace and
| many other tools
|
| * backup - pretty easy to clone vms
|
| * auditing - glad you pointed this out as this becomes _much
| much_ easier; we actually analyzed a _bunch_ of STIGs and
| measured the reduction for each STIG as compared to nanos -
| scroll down to the page here: https://nanovms.com/security -
| essentially if you are in a regulated industry like finance,
| health or defense this is a major benefit
|
| * fs ACLs - we have unveil support and many other nanos
| specific things
___________________________________________________________________
(page generated 2023-07-08 23:00 UTC)