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?
Sure, we trust it!
Let's all store our credit card numbers, addresses, social security numbers, and everything else there.
Perfectly safe.
In No-Security-Allowed America
Your Operating Systems are bullshit.
Your Hardware are bullshit.
Your Internets are bullshit.
Your laws are bullshit.
Your Encryption is bullshit.
Your Cell phones are bullshit.
Your NEWS is bullshit.
If the BSD licence was as useful as GPL then Linux would never have grown in the first place.
Linus is going to kick these C++ monkeys badmouthing Linux square in the teeth.
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. "
an MS-DOS-alike with an alternative API and support libraries.
John_Chalisque
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.
Isn't the point that the VM itself already does the separation?
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
I followed the link for why they chose C++11.
That's great and everything but it's of no use for the user. C++ is about making things easier for the programmer. ALL languages eventually break down into machine code and you are then at the mercy of the compiler designer as far as performance and efficiency goes.
Rather, it allowed us to write shorter code
with less boiler-plate repetition and less chances for bugs.
No, that's not true. I've seen too many times where folks don't quite understand the C++ feature they're implementing do some really stupid or crazy shit.
Folks, programming languages are just syntax - that's all. Sure, I'd write an OS with C/C++ and NOT with COBOL or Javascript (and some engineers I know think assembly is the ONLY way to go!) but if I'm implementing some high level algorithm, I'm gonna go with a language that I'm most comfortable with because they are all interchangeable at a certain level.
Programming is NOT carpentry where "when you got a hammer, everything looks like a nail".
We have screws and nails and hammers and screwdrivers. Take your pick for how you want to drive it.
Whatever you can do in Perl, I can do Python, C, C++, COBOL, JavaScript, etc ...
Granted, until they put a COBOL interpreter in a browser, I'm stuck with JavaScript for client side web processing, but I think you guys get the drift.
tl;dr: Programming languages are just syntax.- none are really better than another. CS 101.
BSD is what OSX and thus OS9 Classic is based on! Virtual all old devices and OS's ever (thus software)!
Ad Populum or Appeal to common practice, with a little bit of Post Hoc thrown in.
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.
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.
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". When you think about it, visualization really is a bit of a hack. You're faking computer hardware so you can segment systems for all sorts of useful reasons.
Of course, parts of that are slow so we optimize the OS so it behaves better as a guest, invent technologies like paravirtualization that shunt data past slower virtualized, emulated, and translated mechanisms.. And now we have an OS that's exclusively designed to be a single purpose guest OS and not run on bare metal at all.
If we continue down this path, and continue to shed redundant OS-isms, won't VMs just become self contained jailed applications running on a host OS? Then you have to wonder if they'll start hosting common resources on the host system (Like a networking stack). Just like applications on a traditional OS :p
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.
Did they really just say that they removed the insolation between kernel and user spaces?
(Re-reads. Yup. That's what they said!)
Oh dear gawds. Do they not realize that this makes their processes naked little unprotected things in a dimly lit room, that are going to be savagely raped and abused by the first rogue process that comes along?
Do they have no conception of why the two spaces are kept apart!?
No thank you, I will refuse to conduct business with any agency that uses this platform, thanks. We have a big enough problem with identity theft and wire fraud as is. I don't want to encourage such a horrifically stupid idea by giving some dumbass led company my business.
http://xkcd.com/927/
OSv, Intel Core i7, ICQ, the cherry tomato, more Nobel laureates than anyone else, the list goes on and on. They even invented a truck that lets soldiers spray foul smelling liquid on Palestinian homes just by pressing a button from inside the confines of an armored cab. Previously, solders had to risk their lives to break down doors and personally defecate on the floors.
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.
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.
So let me get this straight: There is a "Linux in the Cloud" and somebody wants to replace it with something else?
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.
Hey, good luck with that kids. Linux continually replaces itself on a regular basis. Its closest competitor in terms of pace of advance is FreeBSD. Various commercial entities have tried and failed to keep this pace. The landscape of Big Data is littered with GPL-violating Linux rip-offs in development stages ranging from Neglected to Fossilized.
A better investment is to bribe Linus Torvalds to rename his kernel to "OSv".
No surprise, this is /., but have any of you who commented on how shitty this OS is actually looked at it and asked the developers questions before running your know-it-all mouths? This place has really degraded to a shitfest with monkeys flinging feces on any and everything. These guys clearly worked their asses off and produced something novel, yet the small-minded know-it-alls here declare it worthless without even spending any time to look at what was done. You fucks make me sick.
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.
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
You get access to the configuration which can then relay any incoming data to some outside target.
There is also no controls to restrict what that application can do - how would you like it if it was replaced with a shadow server giving out child porn...
You would be liable, and with no mitigating capabilities.
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.
You are a hiring manager or HR person, aren't you. Someone who's clueless about how to really do things - or just a programmer and not someone who was trained in Computer Science or Engineering.
Then you are working with 'tradesman" and not trained computer scientists.
Someone who is skilled in C can pick up Perl and C++ quite quickly, Someone who's skilled in C++ can pick up Java, JavaScript and C# overnight. It all comes down to just syntax and it doesn't make anything easier or harder.
I find it funny that I mention say "It's just syntax" when that was exactly what was drilled into my head in college by me CS professors.
Hug, I see all of this CS is NOT IT or programming here on Slashdot and yet, I see the parent and GP modd'ed as if it were.
Algorithms are what's important.
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?
As a developer one could also worry about stability. If a stray pointer can mess with the TCP stack and other essential sytem services running without memory protection, this sounds like a huge step backwards in productivity. Or do they assume, that programs are developed and debugged in real operating systems and only then deployed into the "cloud" when they are bug free?
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
Maybe you want to be able to control whatever is running in the VM.
How do you propose to do that if you don't have sshd or something similar running inside it?
If you're just going to spawn a new VM for every single program you might as well just run all those programs on the physical machine.
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.
You are criticizing a hammer for not being a very good nail file.
What kind cloud platform gives any single VM any kind of privileged access? You need to take a second look at your cloud platform if its that big of a pile of shit. If you have that problem then you're already up shit creek regardless of what OS you're running inside the VM. If the cloud platform sufficiently isolates the VMs then problem solved at a different level. True, you don't get user space isolation within each VM, but there are lots of systems that don't need it because the architecture is designed with the assumption that the VM is the unit of isolation. If it is designed that way, then it doesn't benefit from user space isolation, and thus it is just a performance black hole.
If you instead, took this OS and tried to run umpteen different things on it, then you sir are an idiot because it was not designed for such a purpose. Sometimes you need a hammer, sometimes you are an idiot trying to use a hammer for something it wasn't intended.
"just have to fix/replace the content": You wouldn't typically deploy PHP in this way to a cloud architecture. If you're going into individual VMs and messing around with files then your wasting your time and someone else's money. You should be able to kill VMs and spawn new ones without any concern for the contents of those VMs. You should NOT be building VMs in the same way you would build a dedicated server.
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++;
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.
Why not? Maintaining a hundred VMs is easier than maintaining a server OS safely running ten unrelated apps under one roof.
Do you run each application with it's own UID? How do you keep one from hogging all the memory? Network IO? Disk IO?
Is each running on its own disk partition? Do you configure disk quotas for your apps? Do you allocate a unique service IP to each app?
How do you manage a cluster of such multipurpose systems? Can you move an application from one node to another easily?
I won't even ask if you can do that without interruption...
Running 12 unrelated apps on one system is almost pointless these days, because server operating systems have stagnated to a point where it's best to just ignore them, popping them out of cookie cutter build servers - one per app, and let the VM software handle isolation and resource sharing.
We really need something like Android or iOS for servers. Low overhead, easy to attach to a configuration management system, and interchangeable. It's not rocket science... operating systems need to present a hardware layer to the application layer and get out of our way. Currently they really fail doing at that.
- Puppet & MCollective admin
It was compiled in Linux,
but it's not linux,
isn't that weird?
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
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.
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'
pretty much accomplishes the same thing with even less overhead and without adding yet another layer of software.
They are on the right track, but it's hard to compare managing jails/containers/zones to managing a VMware environment, for example.
The reason VMware exists at all is because server operating systems have been lagging so far behind what people need. It certainly didn't get to where it is from people needing two run DIFFERENT operating systems on the same hardware, it's because whichever system you use can't do what VMware does as easy as it does it.
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?
You can't just strap two Solaris, RHEL or Windows hosts together like you can some ESX hosts.. think about it.
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.
I'm glad these guys figured out what was holding back people from embracing The Cloud and came up with a solution... ;)
It was the goddamn latency from the userland-kernel isolation and all that pesky C and Assembly code in the kernel!
Good work fellas! I can't wait to experience these amazing performance increases over my dial-up connection!
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.
People who do real computing dont need/use VMs. Why? Because the performance is shit. The whole VM/cloud business is complete garbage IMO and the omly people its going to be useful to are shitty little webapps that arent big enough to be considered useful or important. The business is based on hype and youre all drinking the cool-aid.
Regards
Linus
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...
More like: How to manage 10,000,000 VMs over 100,000 servers in a sane way.
Once you have that many machines, you don't micromanage anything.
LOL! That JS emulator is awesome! But an Osborne with no MSBASIC is no fun!
No, seriously, I just come here for the articles.
I'm not a kernel hacker, but I have the impression that "this" is to Linux as MS-DOS is to (the various) nt-kenel operating systems.
Any thoughts?
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...
The JVM is the OS which sites on top of a hardware HyperVisor. Very low overhead. Context switching between user mode apps does not actually require a context switch.
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).
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.
does it run Linux?
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.
Hypervisor is the OS, OS is an application wrapper.
What have we gained, now?
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 68000 has a pin FC2 that signals if the current memory cycle is priviliged. An external MPU can use this to deny access by pulling /BERR low.
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
Where's the vagrant file?
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
One of the premises of multi-user Operating Systems was the ability to run applications from multiple users on a single system, shielding them from each other. If that had really worked, virtualization wouldn't have been such a big thing right now. But it is, so clearly the multi-user capabilities at OS level are not at the right level. And when we move that to a separate hypervisor layer, it makes sense to remove it from the OS layer. That's just the UNIX philosophy extended: each component should do one thing, and do it well.
That is exactly the point. The problem they are solving is that all current OS's have abysmal isolation between the different programs in userspace so people end up putting different services in different virtual machines anyway. The problem is that you still get the entire ecosystem for a full user OS for every service.
What people are doing to solve the horrible isolation problem that pretty much every OS have is to place a virtual machine (There are other benefits to.) between the OS and the service. The VM essentially works as a firewall between the service and the OS.
The problem with that is that you run yet another OS in every VM and this adds some overhead. (A modern VM by itself adds almost no overhead.)
This operating system adds a solution to that problem by providing a slimmed down OS for that middle layer.
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
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.
Since this is basically talking about running one app per vm, why wouldn't you use/improve one of the many *application* virtualization products out there? There would be less overhead, you would get the base operating system's user separations, and you would get the enhanced virtualization separations.
Funny. Apple only caught up in 2001.
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.
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.
Uh, dude if apps were always secure then you wouldn't need to worry about OS security to start with.
Light weight, integrated with the app in the form of a VM... who needs a big OS just to install the app? The app is the OS and only needs to deploy when needed... I run multiple linux VM's on Citrix xenserver as game, file storage, and application servers... where the underlying OS runs 100% of the time. Bring on this new OS... This play baby wants to experiment!
It sounds like running your 2013 server apps on an OS from 1985 but "in my butt".
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?
You run only one application on the box, so you don't need security. If the application you chose to run on the box does bad things then it isn't appropriate for this kind of operating system. How is this hard to understand. This is made to run big GPL'ed tools like Hadoop, MongoDB, tomcat, VMWare or etc. So your single purpose machine doesn't have to share resources with anything else on the box, because you only want your box running this one piece of software. This is a great thing.
If you have a data center running 100's of Linux boxes which run only part of a Hadoop cluster, then this operating system is for you. Your Hadoop cluster will be faster and easier to maintain.
Only in a system with different users.
Hitler was also tried and tested
An *other* unix baed OS. .....ho hum.. Those who can't read are doomed to repeat history
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.