Oh, I get it
It's like a medieval knight getting a performance boost by not wearing armour.
Virtualization sucks, because it makes it difficult for an application to get the most out of its underlying infrastructure. And so a startup staffed by the originators of the KVM hypervisor wants to change that with an ambitious open source project called OSv. The OSv "cloud operating system" was announced by Cloudius Systems …
This reminds me of the time some guy named Linus announced he'd just thrown an experimental, GPLed 386 kernel over the wall for other Minix users to try out. Today's version is quite a bit more sophisticated. If the fundamental concepts are indeed sound, this could prove to be a very interesting homesteading within ESR's Noosphere.
I don't have a beard, but my mustache is gray. I'm -ex DEC (came in for BSD, got into TOPS-10/20) and HP (un*x & TCP/IP), and consulted for IBM, Sun, and cisco (TCP/IP, sometimes un*x), on and off, for about 15 years. Does that count?
In my mind the entire modern "cloud" concept is pure marketing twaddle, designed to make money off of people who have absolutely zero clue about the nuts & bolts of computing/networking/system security.
Well, you did ask.
Judging by what you wrote, I guess you are one of those people who have zero clue... beard or no beard, a single server architecture isn't interesting in this era. How would you sustain a website / game / saas that has a significant number of users without using some sort of cloud based infrastructure?
What you overlook, is that people pay money to run Linux based virtual machines in public clouds and if they'll use OSv, they will pay less as the mentioned performance boost is directly translated to the amount of virtual machines needed to support a specific workload.
CMS started life independent of the original CP-67 hypervisor development, so it is not a good comparison. GCS, OTOH, was later developed to provide all the MVS facilities needed to support the port of VTAM into the VM suite of products. CMS maintained its ability to be IPLed on bare metal for long time, but GCS never had that ability (or need). CMS did have some MVS (and VSE) facilities including VSAM but nowhere near what was needed for VTAM, particularly multiple task support (process in POSIX-speak).
I have the beard, too (moustache isn't grey, though) and started working with VM around 1978. The VM community inside and outside IBM developed virtualization into a powerful paradigm despite much resistance inside IBM and that history is well-documented. A major pillar was the VM-specific hardware development throughout the process that provided crucial performance gains and also allowed the hypervisor to itself be IPLed in a virtual machine. To our minds, z/VM provides industrial-strength virtualization, as the number of busy Linux instances a mainframe could handle with great stability even over a decade ago testifies. In general we would like to see desktop computers get there, too, while hoping mainframe virtualization will always continue to lead the way.
careful Jake, mention KVM switches and the BBC will report that you're a "sophisticated hacker" using "an advanced technology" (from their coverage of the attack against Santander), think it was last Friday. If you didn't see it, looks like someone managed to put a KVM switch with IP access on a machine within a bank branch, yet the BBC managed to keep a straight face when also saying "no one in the bank was in any way involved" (no-one? who let the person in to the branch and allowed them unsupervised access to the ports on a box?)
The BBC couldn't string together a coherent tech article if their lives depended on it.
A recent article on the 64 bit iPhone 6 and Samsung's announcement that it will move to ARMv8 for its next generation of devices noted that there aren't any 64 bit apps for either iOS or Android. Completely failing to appreciate that most Android apps run exclusively on a virtual machine (Dalvik) and will be able to take advantage of the 64 bit cpu if the Dalvik VM is compiled for it (which, of course, it will be).
The article suggests to me that the JVM is your only line of defence against your entire box being compromised. JVMs are big complicated beasts so the chance of fault or hack circumventing the JVM's protection mechanisms are quite high (because a JVM presents a very large attack surface), and because the JVM is the only line of defence your machine will be fully compromised. Overall the chances of a show-stopping vulnerability look substantially higher to me.
This seems to be a short-cut to making the MIT Exokernel concept a little more palatable to a wider audience. A JVM seems like a good fit because JVMs behave as though they have an entire machine to themselves in any case (selfish memory management, lack of the concept of a PID etc).
It'll be interesting watching the community adding all the stuff to it to make it into a fully fledged OS over the years. :)
Roo: "The article suggests to me that the JVM is your only line of defence against your entire box being compromised."
"Only" being the key word. A few layers less to worry about w.r.t. 0-day vulnerabilities. If this OSv becomes popular, it will also make sure all flaws in JVM will get full attention and quickly be ironed out. This will help all JVM related projects (quite a lot). In the end, this could upgrade Java's current bad reputation a lot too...
Just 2 cents worth.
"The article suggests to me that the JVM is your only line of defence against your entire box being compromised. JVMs are big complicated beasts so the chance of fault or hack circumventing the JVM's protection mechanisms are quite high (because a JVM presents a very large attack surface), and because the JVM is the only line of defence your machine will be fully compromised. Overall the chances of a show-stopping vulnerability look substantially higher to me."
My point exactly
With no other barriers (because you removed them for speed) the JVM is the 1st, last and only line of defense.
A single layer security system.
OK, but I think you guys are missing a really important point here. I very much doubt that people will buy a server and run just ONE of these JVMs, it would be a very expensive way to host apps. What they are more likely to do is to run > 1 of these JVMs and in this more likely scenario the rest of the JVMs and the entire machine are owned. Imagine the fun you could have talking directly to the hardware without a pesky OS to stop you from bricking the machine or spamming the network to death with garbage... Sweet dreams ops guys... ;)
OK, but I think you guys are missing a really important point here. I very much doubt that people will buy a server and run just ONE of these JVMs, it would be a very expensive way to host apps. What they are more likely to do is to run > 1 of these JVMs and in this more likely scenario the rest of the JVMs ...
Ok, a few things have gone awry with this thread.
First, most app deployments at scale run a single application service per VM/ server. There will be other OS services on the machine, but only ever 1 application service per machine. This model fits perfectly, strip away the OS overhead and allow the single app instance direct access to the hypervisor, increasing speed and also security.
When talking about Java security problems, these almost exclusively refer to java applets and desktop Java. Applets especially are broken and have no place in the world today. Server side Java on the other hand has an excellent security record and model.
Giving a JVM access to the hypervisor and removing everything else will reduce the attack surface available against that instance, not increase it. If a JVM becomes compromised, then that is the application compromised, no matter if the host OS is safe or not. The application is the valuable thing, not the host OS, thats just a commodity necessary to run an app.
So removing the host and all its services will reduce the vectors available to attack an application.
"So removing the host and all its services will reduce the vectors available to attack an application."
I strive to keep stuff simple, so in principle I should welcome the idea of reducing the number of components and thereby reduce the chances of having broken components (I really liked the MIT Exokernel work for example). The problem with the scheme presented in this article is that you are throwing out battle hardened layers of security and replacing them with brand spanking new stack of code that has yet to go through that battle-hardening process.
JVMs are very big complicated pieces of code - and they have had more than their fair share of remotely exploitable vulnerabilities, and at the end of the day I see no inherent reason why the folks writing a JVM would be any better at security than say kernel devs.
Also you haven't actually addressed the point that if one JVM is compromised *everything* running on that hypervisor is vulnerable, you merely sidestepped it. I think there is a vanishingly low probability of running just one app on one JVM on these boxes, folks will want to do stuff like deployment and monitoring what the system is up to and that will usually end up being set of services that is installed on each box as part of a standard build.
I don't mind people trying this stuff out, just don't expect everyone to jump into the shark tank with you. :)
ah, I see what your point was now, and it wasn't sidestepped, it was that I don't see this as an issue.
Yes, I would expect people to run multiples of these on the same hypervisor, however, the hypervisor is in charge of protecting itself, and does so. It stops its guests from doing naughty things, whether they are fully fledged multi tasking OS' or something very different, like these app container things.
Eg, You can run your custom OS on AW (which uses Xen), but you wouldn't expect to be able to take over host, no matter what guest OS you run.
I took a look at their website, my interest is piqued by the idea of running C++ binaries. I'll give it a shot (eventually), maybe it'll be another handy widget for the toolbox. Would be fun to try it out on something like a Seamicro style box (suitably firewalled + crew of paranoid sys admin on 24x7 watch natch. :P).
So in principle, this simply means you write applications to use the "IBM PC hardware API" instead of the POSIX API. I guess the intent is to run this under KVM, not actually on the real hardware, so that when one application/JVM fails, it doesn't bring down the whole system.
But what about a network stack? What about local file systems, and remote network filesystems? What about threading? Are these all going to be implemented as Java libraries?
Maybe you pay the price of a context switch when you talk to the kernel, but at least the filesystem and network code you are then using is highly optimised and well tested.
It sounds to me like you might as well just go the whole hog and write your applications to run under DOS. You get a filesystem of sorts; you can load TCPIP.SYS as a TSR; and you can access up to 4G of RAM with HIMEM.SYS.
Virtualization sucks, because it makes it difficult for an application to get the most out of its underlying infrastructure
Hey, we have a contender for Stupidest Opening Sentence of the Week. "Yeah, those damn VM supervisors and hypervisors, keeping me from using all of the hardware resources. Screw this. I'm rewriting all my back-office apps to run on the bare metal."
As previous commentators noted, there doesn't seem to be much that's technically innovative here. So they're using a hypervisor as a monitor to run the JVM. Sure, there's probably some market for that, but the article is more than a little overblown.
This sounds like all the other library OS'es that have been around for a while. Check out : https://github.com/GaloisInc/HaLVM, http://www.xenproject.org/developers/teams/mirage-os.html and http://erlangonxen.org/ ... with the exception that Java does maybe not lend itself that much to implement a lean library OS.
Would like to know, how this is different.
Biting the hand that feeds IT © 1998–2022