Slashdot Mirror
Xen Patches 7-Year-Old Bug That Shattered Hypervisor Security (arstechnica.com)
williamyf writes: ArsTechinca, The Register, and other outlets are reporting that today the XEN project patched a vulnerability in the ParaVirtualized VMs that allowed a guest to access the control OS of the hypervisor. Qubes researchers wrote: "On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again".
The truth is nobody uses para-virtualized VMs anymore. EC2 which was the last bastion for pv xen stopped using it a couple of years ago and moved entirely to hvm model. I'm not even sure that the latest Linux kernel support are compiled with Xen PV support. If you looked at the kernel code for PV XEN support you know what the mess that was so good riddance. You need to understand what PV mode means for hypervisors: a kernel must be specifically modified to talk to a hypervisor so instead of performing a privileged CPU instruction it would call a Hypervisor provided function. I'm sure there were tons of security issues with that approach and many still exists. Anyway PV model is not relevant anymore since Intel introduced hardware virtualization on the CPU. It was introduced to to improve perfromance of VMs but it's not relevant anymore
Every piece of software contains at least one bug.
Also, every piece of software code can be shortened.
Therefore, every program can be shortened down to an empty source file which doesn't work.
"Oh, goodness. Look at my wrist, I have to go." "But what about your clothes?" "I don't love these."
It never really ever had "relevant" market share. Hypervisors only have been in the market for roughly ten years, and its not like they have been running nuclear power plants. Its closest relative, the microkernel, has in QNX, and other proprietary products.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
"Shattered" really?
What the hell is in charge of the Gawker-style headlines, because I think that same robot should be made responsible for editing: at least we know it's working.
-Styopa
ESR Was wrong. Enough Eyes are not enough!
One needs Enough QUALIFIED AND MOTIVATED eyes, as well as proper test cases, a Quality Assurance group and Technical Guidelines.
*** Suerte a todos y Feliz dia!
It was almost as bad as a "if(true == true)" "bug". They should have unit tested this to make sure it failed as expected. Always test your edge cases, and also try to test corner cases. But really. Who doesn't test their edge cases? They're the simplest tests to identify.
Go do LWN's search page, uncheck all the boxes except for "security vulnerabilities", and then search for "KVM". Or Qemu, or Linux or Xen.
You'll find that all hypervisors have privilege escalation bugs discovered. However, this is the first one discovered in the Xen PV interface in a long time.
TCP: Why the Internet is full of SYN.
People who aren't going to participate proclaiming how others should do something.
On the other hand, it would be a good idea to people stop harassing open source projects when serious and/or old bugs are discovered *and* fixed.
Nasty 7 years old bug discovered? Bad indeed.
Nasty 7 years old bug *FIXED*? Good, very very good.
Once you decide not to throw everything through the Windows, I mean, window every year ("fixing" old bugs with new bugs), you must expect that old flaws will one day be discovered. And fixed.
There're too many criticizers nowadays - but almost none of them got his hands dirty to know what they are criticizing.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
that would not let similar flaws to plague the hypervisor ever again
Can we trust people to critique code who can't even manage English grammar?
Yes. Very few program is written in English. C is more common.
And looking at the Qubes OS team https://www.qubes-os.org/team/, I'd bet English isn't the primary language for most of them.
What is the difference between an edge case and a corner case in testing?
For a non native english speaker they seem the same to me.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I have no idea what Hypervisor is but all I keep envisioning is Pin*Bot.
ESR didn't say "given enough eyeballs, no bugs exist."
He said they are -shallow-. "The fix will be obvious to someone". That is, you won't spend a month trying to to figure out exactly why foo sometimes conflicts with widget - with with several people looking at the source (not just the output of the binary), someone will more quickly see why foo conflicts with widget and how to fix it.
It looks like in this case it was about 48 hours or so to characterize the problem, agree on the proper fix, code it, test, patch the major public clouds, and release it publicly. Guessing that patching the public clouds took 24 hours, that's about 24 hours for understanding the problem, discussing it fixing it, and testing. Not bad. Here's a quote from CATB with the context of the "bugs are shallow" part:
---- ... if any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it.
----
It's about bugs not being intractable - they aren't extremely hard to figure out, "the fix will be obvious to someone". That doesn't mean they never existed.
Privilege escalation vulnerability caused by a buggy Memory Management Unit, instead of failing safely - it fails bad ...
The actual bug is shown in the original article. The author says "It appears the seven-year-old Xen bug is caused by an entanglement of C macros, bit masking, and Intel x86's fiddly page table flags" but fails to explain exactly what's going on (probably he doesn't understand it himself). Can some explain what actually happens in this line and what failure modes caused the check to be bypassed?
The fact that such a simple-looking line could result in such seriously flawed code tells me that programming secure code in C is much much harder than I thought, especially when what looks like a clean function call is actually macro expansion, perhaps layers of macro expansion. Mot a fault of C per se, but a gotcha when using a lot of macros as if they were C functions.
You do realize that like, half of the 'cloud' runs on Xen right? Amazon, some of Rackspace, etc etc.
An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter.
A corner case (or pathological case) is a problem or situation that occurs only outside of normal operating parameters
I dumped XEN for VMware last year and haven't looked back. The deciding factor (not to mention sliding market share, lack of compatible backup products, and weak tech support) was a VM simply 'disappeared' due to a faulty clean up process. The faulty process deleted the VM and support told me to call data restoration.. When I asked for the number, he said, "no, I mean your inhouse data restoration, your backup administrator"... VMware has so much of the market every single virtual product or offering just works.
Xen was originally an out-of-kernel patch so KVM had an advantage for a while because it was less work to set it up. But from Linux kernel 3.0 and onwards, Xen is right in the mainline kernel.
Have a read of the relevant sections of the oldest, most original CATB you can find. I think you'll see it says the same thing. You see, he was talking about the (then new) troubleshooting process that Linus had implemented.
The solution to the metafile bug didn't require deep meditation for ten years. If you don't know there is a bug, that doesn't mean it's buried deep, it just means you don't know there's a bug.
Of course to prevent bugs you need educated developers, good testing, etc. That's all true. And has little or nothing to do with what ESR discussed in that passage. Again, he didn't say "no bugs exist", he said "the solution will be obvious to someone" - it's about the process of solving bugs - preventing them is another topic altogether. If you read the four or five sentences BEFORE thehalf of the sentence that became famous, he's talking about a the difference between user who can only see the problematic output of a binary versus someone who can read the source and see which part is going wrong.
To me, a huge value of FOSS is that the vendor doesn't have you by the balls. If you need something fixed or changed, you can hire any of millions of programmers to take care of that for you. It doesn't matter if the vendor has gone out of business, isn't interested, etc. - you're in control of your own systems.
This can be worth millions of dollars to a large business or government agency, because migrating to a different, competing system can cost that much if your current software doesn't fill your need. If you need some piece to handle Euros as well as dollars, a programmer with the open source can probably do that for a few hundred to a few thousand dollars, instead of tens of thousands or even millions to replace the system throughout your organization and re-do all of the integration work, employee training, etc.
That and of course for smaller organizations and families the dollar cost difference can be huge, allowing homes and small offices to have enterprise grade functionality. A router with "advanced" features like QOS can easily cost a thousand dollars or more. OpenWRT is $0.
A corner case would be at an intersection of two edge cases! Almost by definition.
--
no sig for you. come back one year.
My biggest complaint about other programmers is they don't account for the possible ranges of their parameters. Many just want to get the program "working" and nothing more. I don't like undefined behavior. I try my best to design my programs to have all behaviors well defined. When something goes wrong, I can almost always tell you exactly why it went wrong or exactly where to look. I hate the whole, get 20 people involved because no one knows what code is causing the issue and lets spend hours guessing why a program is failing because we don't know how our programs work.
A corner case would be at an intersection of two edge cases! Almost by definition.
Almost, consider a corner involving three surfaces.
This is perhaps the single best question I have seen in a decade.
Bonus point for the asker.
End point case, overflow/out of bounds case, edge case, corner case...
I can offer some obvious, to me, thoughts. ... so does testing for zero in floating point land.
*) End points are sometimes ill defined and the last legal value and first illegal value must be
correct... Off by one bugs fall into this
Often found inside a function.
*) Edge cases would be interface issues between two functions with a single arg()
*) Corner cases functions with multiple args().
This simplicity ignores a lot!
In my experience labeling a bug with a type is more error prone than ....
any type-unsafe language. Consider bogus asserts()
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
By some usage of "rarely". They seem pathological to me. They tend to happen in bursts or start once a threshold is met, in my experience. 80% of my job is dealing with these "rare" corner cases that other people never thought or cared about.