Slashdot Mirror
New Operating System Seeks To Replace Linux In the Cloud
New submitter urdak writes "At CloudOpen in New Orleans, KVM veterans Avi Kivity and Dor Laor revealed their latest venture, a new open-source (BSD license) operating system named OSv. OSv can run existing Linux programs and runtime environments such as a JVM, but unlike Linux, OSv was designed from the ground up to run efficiently on virtual machines. For example, OSv avoids the traditional (but slow) userspace-kernel isolation, as on the cloud VMs normally run a single application. OSv is also much smaller than Linux, and breaks away from tradition by being written in C++11 (the language choice is explained in in this post)."
I'll take my server OS tried-and-tested, thanks.
No security either.
They claim it runs a JVM, but the source code of this JVM is nowhere to be found. Where is it?
If the BSD licence was as useful as GPL then Linux would never have grown in the first place.
I wonder how well it will fare against Zing (http://www.azulsystems.com/products/zing/faq)
Azul decided to go with route of extending vanilla linux with some kernel modules to provide extensions for most critical things, rather then replacing entire system and making custom jvm to utilize these extensions. I have a feeling that it is a lot better approach than using custom OS with plain jvm which is not aware of extra capabilities (if there are any...).
pretty much accomplishes the same thing with even less overhead and without adding yet another layer of software.
"To those who are overly cautious, everything is impossible. "
It boggles the mind that anyone would suggest something like this and then use the excuse of "well we only run on app on a box". That's such amateur hour nonsense. It's like running your cloud apps on classic MacOS or an Amiga.
Just because you've only got "one app", it doesn't mean that you've only got one process.
It sounds like running your 2013 server apps on an OS from 1985 but "in the cloud".
[shake head]
A Pirate and a Puritan look the same on a balance sheet.
Another refreshing feature of OSv is that is written in C++.
It's been 40 years since Unix was (re)written in C, and the time has
come for something better.
C++ is not about writing super-complex type hierarchies (as some people
might have you believe). Rather, it allowed us to write shorter code
with less boiler-plate repetition and less chances for bugs. It allowed
us to more easily reuse quality code and data structures. And using
newly standardized C++11 features, we were able to write safe concurrent
code with standard language features instead of processor-specific
hacks. And all of this with zero performance overheads - most of C++'s
features, most notably templates, are compile-time features which result
in no run-time overhead compared to C code.
You end up taking the bad with the good. And some features in C++ are worth avoiding when you're outside of a nice big userspace runtime. Like exception handling, especially for classes that use multiple inheritance.
L4 is a microkernel and hypervisor designed specifically to run an OSlib in a virtual environment with very little overhead. It seems to me that some things about L4 are very compatible with visualization, being that most drivers in L4 operate as a virtualized environment rather than a process.
“Common sense is not so common.” — Voltaire
This is a language-support library. It replaces the C runtime system, and the bottom levels of the Java runtime system. For environments where a virtual machine is running one program, or a family of tightly related programs, that's all you really need. The real operating system is the hypervisor underneath and the remote management tools that run the cluster.
Linux, with millions of lines of code, just isn't doing much inside a VM. It's not managing the memory. It's not handling real devices. It's not handling real interrupts. It may not even be managing any file systems - in cloud environments, those are usually out on some storage area network. It's just a big fat pig of an OS that needs to be fed patches and attention to keep it going, while not doing any useful work.
Within the virtual machine, there are no security boundaries. This may be a problem if more than one application is running in the VM. But if you only have one big program with many threads running, the OS isn't doing anything for you in security anyway.
When a particular choice of programming language makes the resulting work easier for others to understand and maintain or modify, simply because things have been expressed in a manner that is more natural to understand with relation to what is actually being done, "just syntax" makes a HUGE difference.
File under 'M' for 'Manic ranting'
I was just thinking the same thing... If you're running linux with KVM as your hypervisor... Why is this better than Red Hat's Open Shift? That way you get your cake and you get to eat it too.
Yes Francis, the world has gone crazy.
Where are they "badmouthing" Linux? All they said was that Linux is over-kill for running a single application within a VM. Linux and OSv are different tools for different purposes.
So now I need 12 vm's to perform the same tasks that one vm with 12 apps used to be able to perform? No thanks.
http://xkcd.com/927/
Of course we trust the latest version of NSAOS. ... it's already handled for you.
- No need for userspace separation because we're alrea
- Crypto, shmypto, it's safe!
- You can't spell No Source Available without NSA!
- Trust us! (you really have no choice)
Given that this is a special-purpose OS, intended for one-app per VM situations I think it is a perfectly reasonable assumption to make.
Where are they "badmouthing" Linux? All they said was that Linux is over-kill for running a single application within a VM.
Considering we used to run Linux and our applications in 32MB of RAM and 64MB of Flash in embedded systems, I have a hard time seeing Linux as over-kill for running anything in a VM. The application will probably require more RAM and CPU than the kernel.
You're getting old.
Get free satoshi (Bitcoin) and Dogecoins
well only that app's should be accessible from outside.. if you're worried about breaking out from that app, what are you going to get into that you wouldn't get into in linux? unlimited access to /dev/? who cares when it's sandboxed? I mean, I don't see any need to run anything else on it - it could _really_ be running just one app, if you had your email inbox in there you would be doing it wrong. to get something you wouldn't get on a normal linux box you would need to break out of the vm, no? and that sounds like a bigger barrier than elevating your user on a normal linux installation..
world was created 5 seconds before this post as it is.
In this scenario, processes are kept apart by VMs. They are basically trusting VM security instead of Linux Kernel security (or rather, instead of two layers of Linux Kernel security).
"First they came for the slanderers and i said nothing."
Indeed. They've basically re-implemented the amazing idea of running multiple applications on one machine with a security layer to stop them from interfering with each other.
If they don't have any real security inside the VM, they might as well just get rid of it. The underlying OS will probably be Linux anyway, so they're trusting Linux security in the first place.
since the NSA is so good at cracking encryption and likes to spy on everybody and the US Govt is fascist in nature that means all the good ideas for new products will be stolen and given to government cronies in the private sector
Politics is Treachery, Religion is Brainwashing
With a container you still have the kernel-user boundary to cross on each syscall. I guess with OSv you could potentially optimise the whole OS, libc and application down into a single binary. Yes, it's interesting how this is developing -- Docker as well. Having lightweight containers or OSes like this is really taking off. I guess there may also be a bit more guaranteed isolation running it with OSv, less risk of a kernel bug leaving an exploit path, i.e. the isolation is at a different layer.
It is worth mentioning that it is an Israeli-developed system (even if you didn't read the article, the names as noted in the summary are a dead giveaway), and we all know how chummy the Israelis are with the NSA. Of course there's a goddamn backdoor in it!
-- Ethanol-fueled
If you have multiple, semi-related tools, you currently wouldn't run them as different threads in the same process. Why put all your eggs in one basket, having to restart them all at once, letting one rewrite the memory of another, when starting a new process is so cheap?
Now, if you have multiple, semi-related tools, you wouldn't run them as different processes in the same VM. Why put all your eggs in one basket, having to schedule them all on the same hardware, letting one misbehaving VM affect all of them at once, when starting a new VM is so cheap?
We don't use separate processes because it's the best imaginable model of systems design. We use it because it's been the best compromise between separation and efficiency.
A single process can contain multiple threads. Without some level of protection there, this kind of thing could be more vulnerable to code injection attacks, allowing a perp to own the whole VM. If they do this without upsetting the process in any visible way, they can now just soak up all the data that the VM is having shoveled through it.
Without a kernel space inside the VM looking for untoward behavior from the threads in userspace, and enforcing restrictions on who owns what resources, this is a recipe for trouble. The compromised thread can walk all over the vm's memory, and report whatever it wants to the hypervisor. In this case, the goal isn't to escallate, the goal is to compromise the vm and lay dormant. An actual, real VM with a seperate kernel space keeps important parts of memory secure. Like the data reporting and monitoring threads.
They just removed a whole layer of security. It may well be mostly redundant, but given the stakes involved, redundant security features can actually pay off.
The honor system doesn't work when the threads stop being honorable.
So now I need 12 vm's to perform the same tasks that one vm with 12 apps used to be able to perform? No thanks.
Isn't that what IBM has been doing with VM/CMS for decades? If you have deduplicated physical memory pages, what's the problem with that? (For that matter, am I the only one to whom this looks like a remake of VM/CMS?)
Ezekiel 23:20
That's well and good, until you realize that a typical email server usually has an MTA (postfix, courier, sendmail, whatever), some sort of spam trap/filter (in addition to external ones), maybe a means to more efficiently handle distie lists, SASL auth (postfix typically handles that nowadays, but...), and probably some sort of webmail thingy. That's way more than "one app".
Same with Apache/Tomcat/Whatever - you've got the web engine underneath, the Perl/PHP/Ruby/Python/Java/JavaScript based "app" (or, multiple apps, if you're using some generic CMS as a framework base), the interpreters to handle them all, the DB (or some client-ish means to reach one, such as MQ, ODBC, whatever), openSSL (or some means of handling certs and encryption)... again, way more than just "one app."
Also, speaking of databases, if I can compromise the kernel on the server running that "one app", I can crawl through that "one app", get kernelspace, pop in a shadow app to do whatever I want (and bury it nice and deep - go ahead and sort it from all the other kernelspace files in there w/o a decent IDS)... and long story short, you'd never know I did it unless you paid very close attention to your monthly bandwidth bill.
At least with some separation, a compromised userspace-only "app" is as far as you get. You can pop PHP but not apache (on a properly-built box)... oh well - just have to fix/replace the content. Without that separation, a violated box may well have a keylogger (or similar stdio-copying setup) installed for the express purpose of capturing what you do when you do realize that box is compromised (or even if it you don't...)
Quo usque tandem abutere, Nimbus, patientia nostra?
John C. Dvorak stated in 1996: "The AmigaOS remains one of the great operating systems of the past 20 years, incorporating a small kernel and tremendous multitasking capabilities the likes of which have only recently been developed in OS/2 and Windows NT."
So be careful when linking Amiga with classic Mac...
In 2006 BEA had this kind of bad idea, with a VMware based hypervisor hosting a JVM/OS hybrid to run Weblogic processes.
Original article found: there
Implied ad-hominems aside, while I am "just a programmer", I did receive formal CS training. But that is neither here nor there.
I won't dispute that there is no one language that is going to be ideal for solving all problems, but it's entirely erroneous to presume that for certain types of problems, some languages are going to be better than others simply because the syntax of the language makes the solution more elegant to express and makes the resulting source code easer to understand.
This ease of understanding almost immediately translates to a faster development cycle, resulting in the end user receiving the product earlier, and in general will also mean that the software is less likely to contain unknown bugs (barring unknown bugs in the language implementation on the target architecture or bugs in the software development environment itself), so those choices can even impact the end user, even though they are unlikely to necessarily understand how, or even necessarily be aware of them.
Just because you *CAN* do the same thing in any imperative language that you can do in one particular one does not mean that they are all equally good choices, Choice of programming language should be less about making everything look like a nail because all you have is a hammer and more about picking the right tool for the right job.
Your prof was right... language choice is "just syntax"... but in the real world, "just syntax" makes a world of difference.
File under 'M' for 'Manic ranting'
So this has none of the benefits of C, and all the bugs and problems of C++. C++ forces people away from clean procedural programming, and toward 'computer do it for me" and "I guess it will be ok" highly abstract object oriented rubbish. I would rather tell the computer "do this, then this, then this", rather than "one of these things but hopefully the first, then the second, then the third, other wise bad things happen if you guess incorrectly". Watching a destructor function unravel a stack for example. You can write something that happens to work in C++ if you want, I would prefer something that *absolutely works for sure* in C.
Nope, you're not the only one. That's exactly what I thought too.
Someone who is skilled in C can pick up Perl and C++ quite quickly
Spoken like someone who hasn't actually programmed in C++. I was very good in object pascal, C, and quite a number of other languages when I first started programming in C++.
Lets just say that "quickly" isn't a description I would have for myself or anyone I've ever met when it comes to how long it takes to "pick up C++". Sure, you might be able to write some code in C++ after a couple days, but that code probably isn't worth the price of the storage your using for it. I would guess it takes upwards of 3 or 4 years before a C++ programer is good enough not to be making absolutely stupid mistakes on a daily basis. This is especially true for Java programmers who waltz in and think they know how to program in C++ because the syntax is so similar. The results are usually buggy garbage that compiles but won't run for long.
Heck, after nearly 20 years, I still look at code I write on a daily basis and go WTF was I thinking yesterday when I decided to do that! Or my co workers do it for me during code reviews.
The important thing that the Amiga OS lacked, when compared to a more "modern" operating system was memory protection. Simply because it lacked the necessary hardware to enforce it.
Sadly, there was no provision for implementing any separation even when the necessary hardware was available, which it was on some of the later/high-end models.
c++;
If you're having performance issues, then C++ would offer a more efficient solution. Why jump through all these hoops to boost Java performance? Just use C++ and get twice the performance instantly with Linux. I tend to agree with the AC that the language issue is overblown. With practice programming is about the same level of difficulty with most languages. C++ does a pretty good job at compile time checking, interfaces directly with the system calls and offers nearly all the performance you can get from the computer. (AVX instructions can be done quite well in assembly, but most cloud apps would not benefit from using AVX.)
Unless you have substantial computation or disk I/O, I would expect the bottleneck to be the network. With compute bound apps the OS is irrelevant. Likewise with I/O devices the time spent in system calls is dwarfed by the disk speed.
Ray Seyfarth, ray.seyfarth@gmail.com, http://rayseyfarth.blogspot.com
Shh!!! You're foiling the NSA's plan!
It boggles the mind that anyone would suggest something like this and then use the excuse of "well we only run on app on a box". That's such amateur hour nonsense. It's like running your cloud apps on classic MacOS or an Amiga.
Their premise is that you'll write your app as a series of separate servers. Then you'll deal with inter-server security instead of inter-process security. If two processes are basically parts of the same program anyway, you can run them on the same server so they can share memory.
I think it's a silly idea, but it's not an inherently bad one. It might well make sense for some kinds of workloads. Until we get back single system image clustering on Linux (there was OpenMOSIX) this might help some people.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
How the hell are you running a remotely exploitable email server?
Since this OS is designed to only run one program there is nothing else to exploit.
Considering we used to run Linux and our applications in 32MB of RAM and 64MB of Flash in embedded systems,
Tee hee. My first Linux box was a 386DX25 with 8MB of DIP DRAM and a 1MB Trident ISA VGA card. I did have a whoppin' 120MB of HDD, though. I have run GPE on iPaq (Familiar) but I've got a 128MB+WiFi CF plus the SD slot.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I'm missing a very important 'not' in the second sentence of the second paragraph there... between the words "are" and "going"
File under 'M' for 'Manic ranting'
Not sure what you mean by this. OS9 and anything previous to that has nothing to do with BSD.
OSX was a completely new start. "Virtually all old devices and OS's ever" is most definitely not BSD.
c++;
A single process can contain multiple threads. Without some level of protection there,
I hate to break it for you, but there's no level of protection between threads in a single process, on Linux or any other mainstream OS. Threads are, by definition, sharing the address space, so any thread can crap over any other thread.
"Computer Science or Engineering". When do programmer boys -also the "professor" ones forever walking the halls of "computer science" "universities" finally get it: /Nothing/ in or around computers is science. It's just and only a craft.
Your text is misleading; the difference is only between worse and better craftsmen.
You are holding your C++ "howto" book the wrong way. Of course you need to be highly educated to properly use C++.
But if you have reached that level, you can do things like generic container classes which have bounds-checking, for example. Or your own string class with similar properties. That will immediately kill about 30% of current exploits, as they depend on all the shitty aspects of *real-world* C software-engineering.
Security is by now the most important issue in applied computer science. C++ helps you towards that in a way C can never do.
You get access to the configuration which can then relay any incoming data to some outside target.
IANASA (systems administrator)... but why would this matter? Presumably the host OS would restrict the ports this thing can use. A compromised app on Linux with access to the world on some port could relay any incoming data to an outside target as well... right?
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
C++ allows for much better modularity and for programming on a higher semantic level than C. This boosts security, productivity, correctness and sometimes even performance. But yeah, you need to know algorithms and complexity, you need to know how the machine will implement your stuff, you need to know the machine itself and its performance characteristics. C++ does not magically improve the efficiency of an idiot. But the same experienced guy doing C and then C++ will be significantly more productive in C++, there is little doubt.
Just because it's a craft doesn't mean it's not a science. In fact, many things that are commonly more strongly associated with being art have an amazing amount of science behind them... music being the most notable that I can think of right off the top of my head.
File under 'M' for 'Manic ranting'
It boggles the mind that anyone would suggest something like this and then use the excuse of "well we only run on app on a box". That's such amateur hour nonsense. It's like running your cloud apps on classic MacOS or an Amiga.
Just because you've only got "one app", it doesn't mean that you've only got one process.
It sounds like running your 2013 server apps on an OS from 1985 but "in the cloud".
[shake head]
http://jsmess.textfiles.com/
That emulates a bunch of old computers, even 1985 ones. Runs on the cloud. Just need some server apps for any of them now...
Be seeing you...
It was also single-user, was it not?
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Couldn't you get the same effect by running multiple processes in different cgroups? Sounds like that is really all this is, since the host OS is probably still linux...
LOL! That JS emulator is awesome! But an Osborne with no MSBASIC is no fun!
No, seriously, I just come here for the articles.
OSv certainly appears to be a derivative of FreeBSD (see https://github.com/cloudius-systems/osv/tree/master/bsd).
Brian Fundakowski Feldman
The deployment system should be responsible for the configuration. The hypervisor should be responsible for starting and stopping VMs when the monitoring system determines that they're misbehaving.
SSHing in and changing config files, killing process and deleting unused logfiles or whatever is not a scalable solution.
"The" physical machine? You mean the ten thousand machines across half a dozen data centers where jobs from a thousand different entities are constantly being spun up and shut down in response to load and hardware changes?
Yes, you could do that. This is just an easier way of doing it quickly, transparently and securely.
"What other OS quickly installs to an integrated shared filesystem, does cluster-wide isolation/sharing/balancing of most major system resources, and can move running applications from one node to another in a cluster with almost no impact?"
Sounds like you are describing VMS. VMware moves operating system instances, not applications.
"To those who are overly cautious, everything is impossible. "
How the hell are you running a remotely exploitable email server? Since this OS is designed to only run one program there is nothing else to exploit.
Hmm email server has to handle... emails, duh! Emails are untrusted data coming from untrusted sources, and your mail server is doing complex processing of those emails. So, yes, it is potentially remotely exploitable.
When I read this I instantly thought of Docker. Wonder what the advantages of this are over Docker...
I can hack your server just by sending a email? Cool!
Seriously though, please find a single case of that occurring with any major mail program.
This or something like this will be huge. I remember arguing against linux. Why would anyone want to install that? It's crap written by some college kid. I was extremely wrong, but I learned quickly after Solaris kept getting crappier and crappier.
Those who forget history are doomed to repeat it. See: the Morris Worm. Spread through sendmail (and other vectors).
With virtualization becoming pervasive I wondered how long it would be until people started looking at the bits of an OS that were rendered legacy because they were required for running on "bare metal".
About 41 years ago: http://en.wikipedia.org/wiki/VM/CMS
http://www.cvedetails.com/vulnerability-list/vendor_id-802/product_id-2219/Argosoft-Argosoft-Mail-Server.html
http://www.cvedetails.com/vulnerability-list/vendor_id-31/Sendmail.html
http://www.cvedetails.com/vulnerability-list/vendor_id-86/product_id-143/Dan-Bernstein-Qmail.html
http://www.cvedetails.com/vulnerability-list/vendor_id-1565/Mailenable.html
That's not including the anti-virus that commonly scans the email transversing the system.
What we need is better application isolation on bare metal and not emulation layers.
It was also single-user, was it not?
That is correct. Single-user designs were the norm with personal computers of the era. There are some ways around this (, for example) but they're sort of limited.
The lack of memory protection is due to the first models being designed around the plain Motorola 68000 CPU, which lacks a memory-management unit (MMU). Later models were available with beefier and more feature-rich processors from the 680x0 series, some of the including an MMU. You could also buy add-on “turbo cards” (processor cards taking over the functions of the main CPU, effectively replacing it with a faster one.) But by then it was too late. The OS relies heavily on shared libraries and message passing in flat, shared, unprotected memory space.
Otherwise, the Amiga hardware platform and AmigaOS – the first model/version having been released in 1985 – included concepts such as preemptive multitasking, windowed GUI toolkit in the system ROM (no “text mode” at all), overlapping “screens” in different resolutions and bit depths, hardware blitter and DMA-based I/O (including multichannel sampled stereo sound), drivers for devices and filesystems, the “AutoConfig” system for add-on devices (fulfilling the same role as PnP did later in the Wintel world), 8-bit ISO Latin-1 character encoding as standard, windowed command-line shells, shell scripting, inter-process scripting (ARexx), an OS-provided framework of multimedia “datatypes” (handlers/decoders/players for common file types), scalable fonts, clipboard, speech synthesizer as a standard OS feature, etc.
Ignoring Linux and OS/2 for a moment, in some ways it felt the Wintel camp only caught up ten years later when Windows 95 was released to the masses, and at that point, both the OS and the “IBM-compatible” PC hardware platform were still missing some key features and novel ideas that made the AmigaOS so great and elegant in its day.
One "app" is rarely "one program."
Take web services, for example. The web server ends up launching PHP or Java interpreters, which in turn launch shell commands and access databases. Or do you think you're going to get good performance firing IP messages all over the place to access your databases instead of staying within a single VM instance?
While the concept of this OS fits for something like timed, it falls down badly on the security front for real workloads.
I do not fail; I succeed at finding out what does not work.
Regards
Linus
Linus actually stating a firm opinion? How unusual.
it falls down badly on the security front for real workloads.
One "app" is rarely "one program."
Take web services, for example.
Not seeing how security is an issue in your example. Presumably they all run as the same userid anyway.
Why would you have to 'fire IP messages all over the place'? Any hypervisor worth a damn is going to have a high-performance method of passing messages between VMs without using IP or some such nonsense. There is no reason why a web server VM sending a message to a database VM is going to have any worse performance than a web server process sending a message to a database server process.
Breaks down on the security front? How so, exactly? Every message passed between VMs would have the ID of the originator added to the message somewhere, and that ID would be provided by the hypervisor, not the application. Additionally, security is improved because EVERYTHING runs in user space, and nothing runs as 'root'. You want a network connection? You have a network VM, which does nothing but process TCP/IP packets. Even if there is a flaw in the TCP/IP stack you can't do a privilege escalation because the network VM has no special privileges.
Fails for real workloads? Not really, it's been in use on 'real workloads' for more than 40 years on mainframes.
Because there is no userland, all the applications are running with kernel priveleges. That means a flaw in any of those programs can interfere with the whole software stack, whereas with userland protection the individual processes are isolated from each other by the OS.
Perhaps I'm misunderstanding, but it sounds to me much like AmigaDOS was -- there were hooks for security enforcement calls, but none of them were implemented so any program could stomp on any other program. Sure it was fast, but it sure wasn't secure.
I do not fail; I succeed at finding out what does not work.
You have it backwards. There is no kernel (other than the hypervisor), everything is in userland. Each element of the software stack (network, web server, database, whatever) is a separate VM, completely isolated from the other services. A flaw in any service, no matter what 'privilege level' that service is running at, can not spread past what that service can do. Even if the services are running as 'root' they don't have access to any other service's data or whatever because they are in different VMs.
You get access to the configuration which can then relay any incoming data to some outside target.
IANASA (systems administrator)... but why would this matter? Presumably the host OS would restrict the ports this thing can use. A compromised app on Linux with access to the world on some port could relay any incoming data to an outside target as well... right?
True, but it seems like Linux would have a better separation between the running process and a usable system environment, making that kind of attack more difficult. I'm sure these guys would have thought of that though. It really all just depends what is accessible from the root process. Sounds like fun.
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
I can't see that being feasible. That would mean launching each process as a new VM. The overhead would be insane.
I do not fail; I succeed at finding out what does not work.
Because there is no userland, all the applications are running with kernel priveleges. That means a flaw in any of those programs can interfere with the whole software stack, whereas with userland protection the individual processes are isolated from each other by the OS.
You are not talking about security, you are talking about memory protection. The thing is - a process that stomps on another processes memory in this model would get a memory fault and die under the normal model. The end result is the same either way.
As has been pointed out elsewhere, this is what IBM's VM/CMS system has been doing for more than 40 years. You certainly don't launch a new VM every time you would create a process. You create a VM for, for instance, managing a database. That VM uses what amounts to a high-performance socket interface to listen for work requests from other VMs. The database VM is started when the hypervisor is started, and continues running until it dies or is shut down. If it dies, it can't take anything else with it because it is it's own VM. It can't have any IPC resources tied up, etc, because there aren't any. The only thing that would happen is any other VM with an active connection to the database VM would be notified that the connection terminated.
Internal to each VM the application can do whatever it wants. If it wants to have some sort of process control it can do that, as it is a virtual machine and can run anything it wants.
NSA access all-ready built in?
What a f-ing mess we (USA) always manage to do.
It's the same thing for the most part. The big difference though is that it doesn't require an IBM z-series mainframe to run. I'm not bad-mouthing IBM mainframes. The beasts IBM sells today are rather small, very fast, very flexible, and rock solid reliable. But they use an instruction set that is backwards compatible with that of the IBM 360 series mainframes of the 1960's and their successors, not the x86 instruction set that the rest of the world is using for servers. IBM's VM/CMS has been around for decades and is proven. This new OS has yet to prove itself.
It's really quite a simple choice: Life, Death, or Los Angeles.
Sure, if you're going to architect your code that way. But the benefit of "running Linux applications" would be to use existing application code under this OS. And as I mentioned, a lot of such application code spins processes like a fiend.
Now mind you, one could (at least theoretically) use this OS for the server processes like databases, and a "normal" Linux process for the web server. But then you get into the issue of having to maintain a variety of VM definitions within one cluster, which kind of negates the point of having standard images that are used by multiple customers. It also means that customers are expected to run multiple VMs by default.
I could see providers that charge by the VM rather liking that, though. Soak that there customer. Open your wallet wide. :P
I do not fail; I succeed at finding out what does not work.
Process isolation is one part of security.
I do not fail; I succeed at finding out what does not work.
For a moment I thought they were to replace "Linus in the cloud"
Linus in the sky with diamonds has always been my favo(u)rite.
Probably a lot of the ones that know about Docker asked themselves the same. I can install a JVM in a Docker container, install even the java app on it, and run it directly, no extra overhead, no messing with a shared filesystem with other apps. Is not that in practice what they are proposing to do? If you want a barebones Linux to run all of this, you can use CoreOS as a minimal Linux system to run docker containers.
And over that, you can in that way more things than just run java apps.
If its only needed to run JVM, then no matter what OS runs it, it could be the same version of Linux. The main thing that you don't have (yet) with Docker regarding this is live migration of running containers between servers, as you have with VMWare/KVM/Xen VMs or (not so lightweight) OpenVZ containers.
"I can hack your server just by sending a email? Cool!
Seriously though, please find a single case of that occurring with any major mail program."
People, wake up, this is not some "cloud utopia". If it runs an email server, it can be hacked, it made lots of us learn our sh*t the hard way. And even it is the only thing running in the VM, it can still give someone usable data.
The only thing this whole shebang is good for is that it makes it virtually - hehh - impossible to get to one service by exploiting the weaknesses of another one running on the same server (which in this case shouldn't happen). That's it, nothing more. No silver bullet, just a different way of trying to solve the issue.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
If you read through the slides the core OS is only capable of running a single thread. What this looks like to me is a highly specialized OS that relies entirely on the hypervisor to do everything for it. Its basically a specialized version of Java with enough glue and support to run on a bare hypervisor. They started with Java and just implemented everything it needs to run on a hypervisor. Assuming the JVM is fully implemented it should greatly increase a Java apps performance because its gotten rid of all the extra OS overhead. Because of that you would have to exploit the JVM and be limited to what you can do in Java. At that point you could fully read the file system but on this system the only files on this system would be for that one application. The only password file on the system would be the one for this application which if exploited on a normal system would be all the attacker would have access too.
The very first piece of internet malware was a worm that exploited sendmail on several operating systems, way back in the late 1980s and spread without user interaction (it wasn't an MUA worm like pretty much all of the email worms since, but a worm that really did exploit bugs in the MTA).
See: http://en.wikipedia.org/wiki/Morris_worm
Oolite: Elite-like game. For Mac, Linux and Windows
If you don't need a n extra full fledged OS to run your JVM, maybe you shouldn't have virtualized it in the first place.
Wouldn't make sense to have a tool to manage and deploy self-contained packages that can run the JVM (or whatever) in an isolated way, with the Linux kernel alone?
My other signature is a car
The exact same arguments you are giving can also be used to advocate getting rid of VMs. Why construct an entire VM if you're only going to run one application on it? You can just as easily run it on the bare metal and put the redundancy and failover and all that on the application layer. You don't need an entire virtual machine to just run one application in a single security context. VMs are useful because they allow you to be flexible in where and how you run your applications and operating systems. If you get rigid and only allow a single security context to exist on a VM, you are taking away the flexibility and therefore it's usefulness. People want the extra clutter, since it's easier and thus cheaper to use it this way.
I was promised a flying car. Where is my flying car?
Sure. But the original amiga hardware as a 68000 with no MMU.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
That's well and good, until you realize that a typical email server usually has an MTA (postfix, courier, sendmail, whatever), some sort of spam trap/filter (in addition to external ones), maybe a means to more efficiently handle distie lists, SASL auth (postfix typically handles that nowadays, but...), and probably some sort of webmail thingy. That's way more than "one app".
And in the deployment scenarios that this is intended for, each one of those would be running in a separate VM. If you have lots more incoming mail, you might spin up more spam filter instances dynamically. You'd probably only have a single persistent VM for the storage, but everything else would be scaled dynamically.
I am TheRaven on Soylent News
You don't have 12 VMs. You have 12 kinds of VM. You have tens to thousands of instances of those VMs, depending on your load.
I am TheRaven on Soylent News
Especially since Linux was the first hypervisor they ported to, and has the best support at the moment.
TCP: Why the Internet is full of SYN.
The main advantage of VMs over processes is that they have a much smaller amount of OS state. In a VM, almost all of the state is within the VM. There's a tiny amount for the PV devices, but that's it. In a POSIX OS, even the state associated with the file descriptor table is huge and then there are things like locks that are blocking in the kernel and all of the state that is associated with the scheduler and so on. If you want to move a process from one host to another, it's decidedly nontrivial, especially if it has open files and sockets. Hypervisors, however, are designed to suspend, resume, clone, and migrate VMs.
I am TheRaven on Soylent News
Hum, in most large deployments, the databases are not even in the same machine, let alone VM, as the web server. This is the only way to ensure you can scale (adding more web servers dynamically) and optimize the systems for their workloads.
For example, see the Stack Overflow architecture: http://blog.serverfault.com/2011/09/
Frankly, if you're running the RDBMS on the same server as the web service, you're - like me - running a toy database.
Dilbert RSS feed
Where are they "badmouthing" Linux? All they said was that Linux is over-kill for running a single application within a VM.
Considering we used to run Linux and our applications in 32MB of RAM and 64MB of Flash in embedded systems, I have a hard time seeing Linux as over-kill for running anything in a VM. The application will probably require more RAM and CPU than the kernel.
We used to run Linux on a hell of a lot less than that. But that was a different Linux.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I can't see that working well, unless they mean no heavy-weight processes, which have their own address space.
Ne mæg werig mod wyrde wiðstondan, ne se hreo hyge helpe gefremman.
You rant a nice rant but which license is the most widely adopted and whose code is the mode widely used again?
It ain't BSD powering Android.
The BSD advocates are all "Our license encourages sharing, ignore the fact nobody uses it and nobody shares it, waah why is Linux so much more popular!". BSD is a good license for example and throwaway code but for code you value and for which you want people to continute back their chances, for a community effort, the GPL is the license to choose.
And so far, historic evidence, the examples of who likes BSD (MS and Apple) and who like GPL (everyone else) shows me exactly what each license achieves in the real world.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Take web services, for example. The web server ends up launching PHP or Java interpreters, which in turn launch shell commands and access databases.
Wow... really? I supposed that's one way of doing it. Most Java webservice providers just listen for network connections and do everything themselves rather than spawning new executables, but if you're truly nostalgic for old-school CGI I guess you could spin everything up and down all the time.
You're special forces then? That's great! I just love your olympics!
Note: I am not the original poster.
Using some mail servers I setup as an example, it is built up of numerous separate programs and offers access through a lot of different protocols.
Only service that is separate from the servers is LDAP authentication, but there is also numerous on-system intrusion detection services (as well as external) which wouldn't work without being on the same server.
Yes.
/etc/security/limits.conf
iptables with QoS
/etc/security/limits.conf
No, because they all share data between each other.
No, just users for their e-mail quotas.
No, because IPs are expensive and some places won't even allocate you more external ones anymore. Nor is it necessary.
The command line (monitoring is separate issue all together).
No, but I can create a new server instance and have it begin clustering within a few minutes (most of that time is spent waiting on the VPS provider).
I could do that without interruption because of fail over.
In theory, almost every single process could run on their own VM, but I get the impression it wouldn't be cost effective and I am not convinced VM software can do resource sharing more gracefully?
As an example of resource sharing, Storage Area Networks as a prime example become more of a headache (they slow down and become more of a performance bottleneck) when they require atomic synching of events (which is a good thing for most application uses), which is less of an issue when there are fewer virtual servers accessing the SAN filesystem as a whole.
The only thing I can think of that would meet this criteria of usefulness is a TeamSpeak server I am running on a crash report processing server. The crash report processing system has several different applications for processing reports, while TeamSpeak is just there because buying another VM is pointlessly costly for the purpose of just TeamSpeak.
Change is certain; progress is not obligatory.
We don't need to reinvent the wheel here. I don't see why there are claims that Linux can't be scaled, because it CAN. Recompile the kernel to suit your needs. If it's for virtualisation, then do so.
well only that app's should be accessible from outside.. if you're worried about breaking out from that app, what are you going to get into that you wouldn't get into in linux? unlimited access to /dev/? who cares when it's sandboxed? I mean, I don't see any need to run anything else on it - it could _really_ be running just one app, if you had your email inbox in there you would be doing it wrong. to get something you wouldn't get on a normal linux box you would need to break out of the vm, no? and that sounds like a bigger barrier than elevating your user on a normal linux installation..
Not only that, at a very basic level, you already have a kernel - the hypervisor - acting as a kernel. So on top of that kernel, you have another kernel running, and on top of that user space, it doesn't seem to make much sense. Rather, running a barebones monolithic OS, w/ the hypervisor providing all its services, sounds like a good way to go on the cloud.
Of course, one could then say that running Windows 3.11 would then be fine, and depending on the application, it might. Actually, if someone wrote a 32-bit version of Windows 3.11 - something that could run all win32 apps - and then released it, it would be ideal to run on VMware, VirtualPC, HyperV and so on. No need of multitasking - just run one app in every VM that is created, and you'll get good isolation. Such an app would just run on a single core all the time, leaving other cores available for other sessions
Okay, how does this work with, say, a program like Firefox that has mutiple tabs? Since each tab is treated as a separate process, as opposed to a thread, would a misbehaving tab then bring down the entire VM?
Only in a system with different users.
If you recall, that was the model that VMware originally used as well (the VM/CMS model). But, essentially, yes, you are right. I'm wondering why they went with the single threaded process, and would like more information from them outside what is in the slide deck..
mkilpatric, to all the mysterious people, I am the folded dollar.
The thing is, this new operating system will evolve like just about every other "we'll make it smaller and simpler" systems. If they are the next big thing, then sooner or later they'll go down the path of adding everything into their system that they ripped the other guys for having, then act like they invented it.
This is my sig.
Many VMs run one application, but they typically run many processes. For instance OpenSSH. Say a hacker breaks into your application and has some abilities in the userspace. Now with your reduced separation between the kernelspace and userspace it is presumably easier to exploit the kernel. Once you have your way into the kernel you have the run of the place so you have root access to modify all of the other processes running on the machine.
If you are using a password to login to your system the attacker can get into the OpenSSH service and wait for you to login (giving them your cleartext password). OpenSSH uses a tunnel to encrypt your password from the outside world but it is a tunneled clear text password so once the service itself is exploited you end up just handing it to the hackers. Or on second thought just break your way into PAM and then all applications on the machine start feeding the hacker passwords. Once they have your password they can start to use it elsewhere on your network to see what else they can get into.
External facing machines are often just the start of a hackers goals, and making those external facing machines any easier to compromise for the sake of efficiency is a bad idea.