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)."
No security either.
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. "
Looking for holes in windows is like looking for saltwater in the pacific ocean.
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/
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.
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."
I'll take my server OS tried-and-tested, thanks.
Even moreso - I prefer my server OSes to have that kernel/userspace separation. Sometimes that's the last line of defense against a fully-compromised system (see also, say, the typical crappily-coded PHP "application" that has the typical great big security hole (or four) in it...)
I get the drive for making the OS as thin as possible, but sometimes folks need to stop and think it through a little before they commit to doing it at all costs.
Quo usque tandem abutere, Nimbus, patientia nostra?
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
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...
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'
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++;
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.'"
This is for the scenario where said last line of defense is meaningless. When your VM is, essentially, all about running a single process, like a webserver, the only thing that's behind the aforementioned last line is the kernel itself... and nothing else. In other words, there's no practical difference here between one particular userspace process being compromised, and the entire OS being compromised, since that process is the only thing that matters. It's also not a situation where you try to clean up the system if it has been compromised - you just scrap the VM and re-create it from a snapshot.
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'
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.
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.
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.
It's a very good idea, with more finite applications in the real world. Think about it:
1) low, low, low attack profile
2) your kernel and outside perimeter better be perfect, but this is true in the real world anyway
3) less fuss and muss
4) low, low overhead instead of having to strip out init.d junk and daemons-without-a-cause
5) nice paravirtualization instead of sloggy driver emulation
6) modifiable kernel that can be altered so that memory entrance points can be scrambled up easily to prevent addressing hijacks.
So put your favorite httpd on it and run it more as an app virtualization rather than a whole freaking OS/app instance virtualization.
---- Teach Peace. It's Cheaper Than War.
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.
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.
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.
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.
Why jump through all these hoops to boost Java performance?
Because Sun's marketing department was better than AT&T's marketing department.
There are plenty of operations for which a JVM is actually faster than a C process ... and Hotspot runtime optimization has access to a lot more information about how code is actually being used than static compile time optimization - the difference that makes can be remarkable.
Very interesting, and oft cited as a defense of Java's speed. Now show me the benchmarks.
there are a great many applications out there for which converting to C++ (for example) would not give any kind of performance boost (and may even be slower)
Actual experiments and measurements?
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.
In the real world, people are doing what these guys do already, except they use Linux as a guest OS as well. That's why the project got started in the first place - to improve efficiency of a very real use case that's already there.
Sure it can be running just a single application.. But the thing is that a system usually interconnects with other systems so if a system gets fully compromised then it can be used to gain access to more systems...
If the only thing that system is running is a single process, then the only interconnects with other systems that one has are the ones used by that process. So if you can break into the process, you can already sniff and control any of that - authentication information, etc. The worst case here is that an attacker can take down / take over several worker processes rather than just one; but from a security standpoint it matters little since they are all on the same privilege level. And if you're doing that kind of thing in the first place - spinning up servers on a hypervisor in the cloud - then you probably have more than a few of them, so compromising just one isolated VM is not much of a DoS.
Anyway, the whole point of isolating VMs like that is so that even taking full control of one of them is not going to give you anything interesting. That's how you're supposed to set them up in the first place.
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.
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.
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!