Zerg: Boot a VM instance per request, all in under 250 ms
zerg.erlangonxen.org
zerg.erlangonxen.org
But doesn't that mean we are merely reimplementing old concepts on a new level? Almost everything we do on VM level we already did on process level:
- Read-only VM images are essentially like statically linked binaries, just better encapsulated when they run.
- Tiny, fast loading VM images are essentially stripped static binaries with dead code elimination.
- Starting those by incoming network request is just like old "inetd" versions started custom handler programs on each request.
- Same with CGI, just on HTTP rather than TCP level.
- Manual maintaining the lifecycle of those VMs like FastCGI in nginx.
- Maintaining the lifecycle of such a started VM is essentially like FastCGI in Apache (or nginx + auto-spawner).
The only real difference is the improved encapsulation (controlled network access and resource consumption) of the running code, isn't it?
What might come next?
- Multiple VMs could share the same images to save memory, essentially reinventing shared libraries and dynamic linking.
- Network traffic into and out of a VM is controlled more tightly, reinventing SELinux. (Perhaps followed by noticing that these profiles are hard to maintain, rediscovering the maintenance issues of SELinux systems.)
- Providing the network traffic shape directly with the image, so these can be maintained at a single place, by the original developers. This would reinvent Pledge.
- Introducing permissions for network traffic, e.g. such that just one group of application VMs can communicate with the database VMs. Ideally with an ACL system as used for managing file permissions. This would reinvent Unix Sockets.
It would be more interesting if we just made more sandboxing powers available for traditional processes, though there is already quite a lot of sandboxing available for Linux processes...
CGI starts a process per request. fastCGI can reuse processes. Problem already found and solved 20 years ago.
catern@home ~ $ { timeout 1 sh -c 'while :; do /bin/echo foo; done'; echo; } | wc -l
1542
Also, I quite agree that CGI is a bad way to do things, but that's what the original post is proposing. :)
You just described containers :)
Most of that is not really necessary if you are just coming from a standpoint of "I want to sandbox a process". Indeed, if you just want to sandbox a process, just run it under a dedicated non-root user account, and it won't be able to unduly interfere with the rest of the system.
This is simply not true, unless your definition of "sandboxing" only means "run it under another account" and absolutely nothing more -- but under this definition, non-root processes can 100% interfere with the rest of the system without proper control being put into place. "Intereference" can mean a lot more than "writes to my ~ dir" -- for example, monopolizing a system resource (e.g. IOPS or network bandwidth), adding code to the kernel (module autoloading) or simply using a resource at all when it shouldn't, or rogue problems like termination of a hostile/stupid set of processes (cgroups and namespaces are one of the few reliable ways to kill process groups in non-racey ways, etc).
> Most of that is not really necessary if you are just coming from a standpoint of "I want to sandbox a process".
No, a substantial amount of it is necessary if you actually want to sandbox a process in a way that's remotely isolated from the host system. Use cases like Flatpak and Docker are nice, but merely byproducts of the design that allow custom mount namespaces, etc. The original use cases for namespacing, cgroups, etc was precisely to give more fine-grained resource and isolation control over existing applications, in a hierarchical manner.
People have been placing ulimits on users to limit their resource usage for decades, using cgroups to do it is not a novel concept, just more effective.
>rogue problems like termination of a hostile/stupid set of processes (cgroups and namespaces are one of the few reliable ways to kill process groups in non-racey ways, etc).
The ability for a user to leave processes around on the system has been fixed for years now, with systemd-logind which puts each user in its own cgroup.
>adding code to the kernel (module autoloading)
This is a concern both for container systems and regular user isolation, and the only reliable way to fix it for either is to disable module autoloading, or at least restrict the available modules to well-maintained ones.
>The original use cases for namespacing, cgroups, etc was precisely to give more fine-grained resource and isolation control over existing applications, in a hierarchical manner.
Yes, and they failed. The design of Linux namespaces and cgroups is awful. You can perceive this by the fact that they require privileges to use. Hopefully in a few years all this Flatpak/Docker churn will output some namespacing APIs for Linux that are actually good.
That is a common myth that is circulated, and it is a falsehood. Ironically, control groups are subject to the very race conditions that you mention.
* http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html
Contrary to your article, I think systemd's logic also exits in guaranteed finite time even with adversarial scheduling. You didn't take into account the fact that systemd is (I assume) not reaping zombies when it's doing its kill-loop. Each zombie that is left unreaped occupies a pid. Eventually, pids will be exhausted and processes inside the cgroup will no longer be able to dodge kill() by forking off new processes.
Your supervise isn't a "superior API", of course. It does a whole bunch of parsing and constructing human-readable strings at runtime, which something that the 1980s and 1990s taught better than to do. A proper directly-program-usable binary interface actually already exists, as used by Daniel J. Bernstein's original supervise program from daemontools, and has been in widespread use for two decades with a whole bunch of tools in toolsets from a variety of people that speak it. I am one of the people who has documented it in detail. See the manual page for my service-manager command.
You are at about the same level that the supervise in Daniel J. Bernstein's daemontools was in (if memory serves) 1996, before experience taught some very important lessons about the daemonization fallacy.
Not only can Daniel J. Bernstein's daemontools demonstrate some very important lessons, so can the humble ps command (which uses "status" not "stat"). The systemd people (and indeed, again, the humble ps command) can teach how to loop over all of the processes in a system without including process #1 and potentially issuing tens of thousands or even millions of open() and kill() system calls almost all of which are useless and fail. Daniel J. Bernstein's UCSPI and systemd's LISTEN_FDS mechanism can teach ways of telling programs about the inherited open file descriptors that they are to use, that will interoperate with existing tools such as fifo-listen.
And even Stack Overflow can teach the error of assuming that sizeof(bool) is 1. (-:
Sorry, what are you even talking about? I pointed out a specific mechanism by which the following assertion made by you:
>A program that forks new processes quickly enough within the cgroup can keep systemd spinning for a long time, in theory indefinitely as long as suitable "weather" prevails, as at each loop iteration there will be one more process to kill. Note that this does not have to be a fork bomb. It only has to fork enough that systemd sees at least one more new process ID in the cgroup every time that it runs its loop.
might be incorrect. (That mechanism is that pid exhaustion will happen eventually, as long as systemd doesn't collect zombies.) Why don't you read the systemd source to confirm that this bug really does exist? Or at the very least, amend your article to admit that you have not done so!
I only know for a fact that my own "supervise" does not have this bug, and since I am using kernel APIs which were originally created by the systemd developers, I would guess that systemd does not have this bug either. But you're the one stating as fact that systemd does have this vulnerability, so I think you have a bit more of the burden of proof! :)
Anyway, regarding your other comments about my supervise utility. Yes, it has a human-readable plain-text interface, so what? It's still got a feature that no other tool has: It allows daemons to fork off their own children, without any risk of bugs causing stray processes to escape supervision, without requiring privileges. I would love to learn of another tool (on Linux) that has this feature, so please tell me! djb's supervise certainly is not capable of this, nor is nosh, nor is any other daemontools derivative that I know of.
>before experience taught some very important lessons about the daemonization fallacy.
What exactly is that fallacy? :) Perhaps you just mean "daemonization is a bad idea", in which case I fully agree?
>The systemd people (and indeed, again, the humble ps command) can teach how to loop over all of the processes in a system without including process #1 and potentially issuing tens of thousands or even millions of open() and kill() system calls almost all of which are useless and fail.
Yes, my supervise utility is currently not very optimized at shutdown, so what? Starting and stopping processes is a rare operation. :) I will optimize it later, when optimization is needed...
>Daniel J. Bernstein's UCSPI and systemd's LISTEN_FDS mechanism can teach ways of telling programs about the inherited open file descriptors that they are to use, that will interoperate with existing tools such as fifo-listen.
A little condescending, don't you think? I am well aware of these tools. They hardcode logic about where to find file descriptors. I prefer the CloudABI argdata style, explicitly passing in the file descriptor number to use, so that conflicts can be avoided. I find that explicitly passing in the fd number allows for more interoperation with existing tools, not less.
We'll just keep building layers as manufacturers try to lock the lower ones down :)
See WeChat in China for a good example on Android
Basically, the cost of spinning VMs is coming down drastically (with Hyper.sh and Intel ClearContainers offering 200ms boot) and it is now feasible to run your apps on a personal cloud sandbox. You data resides in that box and runs code you have approved; away from the prying eyes of FB, Google and the government. Everyone's facebook will be an individually hosted app, talking to each other over agreed upon protocols; as opposed to exchanging data within the facebook infra.
Of course, a lot of UX and engineering problems need to be solved along the way. Provisioning a personal sandbox cannot be any harder than creating an account on a Social Network. Beiber's sandbox will need to distribute data to 105M followers efficiently. You'll need to patch vulnerabilities at scale, so there needs to be some trust model for applying patches. You need relays to overcome censorship etc.
I tried to solve this problem using derivative regular expressions as graph queries
paper: http://onlinelibrary.wiley.com/doi/10.1002/spe.2226/abstract
source code: https://github.com/amitport/graphpack
(there are other solutions, I admit this is just a plug, but it will be great if it could gain traction)
The main issue just now is that writing (or deploying) IndieWeb platforms and hosting them is the preserve of geeks, and it will not take off and displace current platforms until we can make it trivial for Mom and Dad to join us.
Unsurprisingly, it is not used by “normal” non-techy people.
Now that I think of it, spiders/bots might activate it beforehand. You could use robots.txt, but not all spiders/bots seem to follow those "rules".
Food for thought!
Sidenote: some customers might use monitoring :)
However, is there a point in shutting down the VM right away, other than being a cool demo? It seems to me that you could quite easily keep it around if there are more requests queued, and quickly spawn more workers if the queue gets too long. So a regular worker pool, just that the number of workers can be adjusted relatively quickly.
Whether that'll be worth the cost remains to be seen - 250ms is still far too long for most uses, but if it can come down enough, it's attractive.
Also worth noting I wrote a bunch of benchmarking tools to help optimize this case[2].
[1] http://oirase.annexia.org/tmp/paper.pdf
[2] https://github.com/libguestfs/libguestfs/tree/master/utils
I really hope this can be pushed further down to the point where it gets viable to for more use cases. Of course, we can always use something lighter than Linux, but being able to start with Linux and pare down is potentially so much easier for many types of applications.
Isn't this just cgi-bin, right down to the long startup time and lack of persistence?
"Prefork" these VMs by spraying that image over physical memory in advance, jump to them on a request. memcopy a new VM over them on exit.
VM spawn rate should be the memcopy rate, if the MMU is powerful enough, should only be the amount of memory mutated during a request.
But you can reach comparable levels of isolation with processes: just use Linux namespaces.
Slightly off-topic: the page lists be time for an android phone to boot as 50 seconds. Is that correct? I remember iPhones used to take forever but I recently realized that they sing to boot extremely fast. I have no idea when that change happened.
I’m sure it’s technically more secure than a sandboxed application running in its own VM in its own process but by how much?
My iPhone 8 was 20s to login screen. It basically instant once I login but that may be because my password takes a while to type and it’s loading the rest while I type.
Actually I had to do it twice because the first time it installed a system update, but even then it only took 26 seconds to install, finish booting, and show the lock screen. System updates have been seriously optimized in the last few Android releases. They used to take like 5 minutes.
On the Pixel phones Google uses two system partitions. One is the one you're currently running and the other one gets the update applied to it in the background without you having to stop using your phone. When you reboot it just has to flip which system partition it boots from and maybe do some first boot actions. If the phone starts up successfully it'll then apply the update to the original partition to keep them in sync.
So I tried rebooting with all of my apps exited. 25 seconds.
Actually slower than I thought. I found an old blog post that says an iPhone 5 took about 35s, the slowest of the models they tested.
2x is nice but maybe it didn’t improve as much as I had thought.
https://www.ifixyouri.com/blog/iphone-6s-bootup-time-compari...
Given that this was written roughly 4 years ago (guessing by some dates on the site), its not clear what their support looks like for newer features like maps might be.
Performance looks good (relative to BEAM) but they are also single-threaded which means you'd need to cluster your instances to do multi-processing... and I'm not sure that'd mix well with ephemeral nodes. They talk a little more about this on their site: http://erlangonxen.org/more/clustering
So to recap instead of the typical stack of:
Erlang Code | BEAM VM | Linux or other OS | VM or Hardware
Erlang Code | Ling | Xen | Hardware
Yes there is obvious irony here with the demo not handling requests well after the HN frontage hug of death, but I think it is still a beta / experimental product, it has been around for a good number of years and is somewhat abandoned. If anyone knows more please feel free to correct me.
I know loading JVM based applications have horrific startup times on cold boot, but I was just wondering could you run the JVM directly on top of Xen?
http://www.skjegstad.com/blog/2015/03/25/mirageos-vm-per-url...
Is it considered "stable" or is it simply abandoned? Are there any successors? Near zero overhead VM acting on data storage is something I'll need for a planned project of my own.
I'm thinking of building something here for static sites as an open source project/spec. If anyone is interested in bouncing ideas on this, please ping me via email (in profile).
(it would no longer be strictly static, but the idea is to decouple site from hosting/compute, so it would be easy to port a static/dynamic site between providers at the switch of a DNS entry).
> The demo is limited to 16 concurrent instances and 2 libvirt connections. Due to these limitations we were unable to spawn a new instance to service your request. Please try again later.
Kool.
If your VMs are truly cheap, and you've ironed out the kinks from your proof-of-concept, you'd obviously set up your production system to run more than 16 of them.
Obviously no one would ever run something like this 1 vm per request thing irl.
I can see plenty of use-cases for doing just that. Large uploads, time-consuming request/responses such as server-side data processing, RPC, as a backend behind a caching front-end so that it only has to respond to invalidated cache entries, etc.
I don't see many people using this to actually serve general website requests though. It'd probably be modified to serve multiple requests until nothing is left to do and then exit.
I see phase A from 126.3 ms to 187ms.
Ah, there’s the rub.