A Quick Understanding of Full Virtualization and Paravirtualization
-
When do you choose PV, Virtualization with PV Drivers or straight virtualization?
This is actually pretty simple. PV is by far the best choice and you want it whenever possible. Lowest overhead, most stability. If it exists, this is what you want.
If you cannot do a full PV install (for example, if you don't have Xen and you are not installing Linux) then you are forced to go for regular virtualization and use PV Drivers if they are available for you.
You always want as much PV as you can get. Full PV when possible, PV drivers when not and going with no PV at all is purely a fallback for when there is simply no other choice.
-
I've seen a couple articles that state you get better performance with PVHVM vs PV. Is this true in your experience?
-
me also i read it in this article, they said Debian in PVHVM is 2 or 3 times faster than Debian PV,
https://xen-orchestra.com/blog/debian-pvhvm-vs-pv/
so based on your experience Mr Scott that is not true, right ?? -
@johnhooks said:
I've seen a couple articles that state you get better performance with PVHVM vs PV. Is this true in your experience?
Should not even be possible. I've only seen that from places that seemed to be trying to show that other platforms were keeping up with Xen's speed.
-
@IT-ADMIN said:
me also i read it in this article, they said Debian in PVHVM is 2 or 3 times faster than Debian PV,
https://xen-orchestra.com/blog/debian-pvhvm-vs-pv/
so based on your experience Mr Scott that is not true, right ??I've seen rS making this claim. The only reason that I can imagine that this has value is if the hardware assistance has become that highly perform any. Which would indicate that there is simply more tweaking to be done to the PV model to leverage the hardware fully.
-
Ok thanks. Here's one article, if you wanted it. http://www.frederickding.com/posts/2014/07/pvhvm-centos-7-xenserver-312113/
-
Does providing this level of access to the hardware remove any of separation strengths of VM? In other words, would Viruii, etc have an easier time breaking out of their containers because they are PV instead of HVM?
-
@Dashrender said:
Does providing this level of access to the hardware remove any of separation strengths of VM? In other words, would Viruii, etc have an easier time breaking out of their containers because they are PV instead of HVM?
Theoretically, yes. But the separation is still complete. It's good to wonder, but there is no known (to me) threats that use either.
-
@scottalanmiller said:
@Dashrender said:
Does providing this level of access to the hardware remove any of separation strengths of VM? In other words, would Viruii, etc have an easier time breaking out of their containers because they are PV instead of HVM?
Theoretically, yes. But the separation is still complete. It's good to wonder, but there is no known (to me) threats that use either.
There was a threat recently found in, I think it was, ESXi through the floppy drive controller that would allow one VM to break out of it's container and access the hypervisor, and the other VMs. Though I don't believe it was ever found in the wild.
-
I think the biggest threat is the oversight of the code rather than the technology approach. If security is the top concern then the open source aspect of Xen is a big deal for security. Far more important than PV vs FV.
-
@scottalanmiller said:
I think the biggest threat is the oversight of the code rather than the technology approach. If security is the top concern then the open source aspect of Xen is a big deal for security. Far more important than PV vs FV.
Traditionally I'd agree with you. But the reality is that the code is rarely audited. How long was that bug in OpenSSL before it was discovered? A decade, wasn't it?
-
@Dashrender said:
Traditionally I'd agree with you. But the reality is that the code is rarely audited. How long was that bug in OpenSSL before it was discovered? A decade, wasn't it?
That's not a useful example. One anecdote of an undiscovered bug leads us nowhere. You can't assume that "more" and "better" mean perfect and that a lack of perfection suggests that more and better are not true. Open source is a more secure model. Just because a model is secure does not mean that every project using that model is secure, either. It's the approach that is more secure.
Also, that open source projects announce when a flaw is found (and was patched in hours) actually reflects just how secure they are and should be counted in their favour not against them. Closed source projects have decades old flaws too, but rarely announce it and rarely have a good way to prove how long the flaw has been around.
And that code is actually audited all of the time. Companies like Red Hat, Suse, Canonical, IBM, the big banks, big governments, Linux Foundation, etc. are constantly auditing code. No code is or ever will be perfect. We are looking for better, not perfect.
-
@Dashrender said:
But the reality is that the code is rarely audited.
Again, you are looking for perfect. Rarely audited is still better than never audited.
-
@Dashrender said:
@scottalanmiller said:
I think the biggest threat is the oversight of the code rather than the technology approach. If security is the top concern then the open source aspect of Xen is a big deal for security. Far more important than PV vs FV.
Traditionally I'd agree with you. But the reality is that the code is rarely audited. How long was that bug in OpenSSL before it was discovered? A decade, wasn't it?
If I remember correctly a lot of open source companies (ones that sell support) actually have bug bounties where you can be paid for finding bugs in the open source software. As opposed to certain closed source vendors who have threatened lawsuits against people who reveal vulnerabilities.
-
@scottalanmiller said:
@Dashrender said:
But the reality is that the code is rarely audited.
Again, you are looking for perfect. Rarely audited is still better than never audited.
I'd argue this point at this time. If you really want to find something to exploit, you might have an easier time with it today in the sea of Open Source software (again I point to OpenSSL). Who knows how long the NSA knew about that problem and just didn't report it, and why did they know - it's just as likely that they stumbled upon it as it is that they scoured over the code and found it.
-
Now, does this mean to stop using Open Source code, no of course not. Just be aware.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But the reality is that the code is rarely audited.
Again, you are looking for perfect. Rarely audited is still better than never audited.
I'd argue this point at this time. If you really want to find something to exploit, you might have an easier time with it today in the sea of Open Source software (again I point to OpenSSL). Who knows how long the NSA knew about that problem and just didn't report it, and why did they know - it's just as likely that they stumbled upon it as it is that they scoured over the code and found it.
Completely not relevant. Open source will ALWAYS be more secure then closed source code, simply because it IS reviewed by a third party.
Want an example of how bad closed source code is? EverQuest.
EQ was reverse engineered in less than a year to the point that people were able to being injecting their own packet data into the stream. After 2 years it was almost completely exposed. Things like MacroQuest were developed.At the same time other people began to actually make use of that hacked information and began to create the first EverQuest emulators.
Today, there are Emulator servers with hack detection so good that it is (so far as is publicly known) not possible to play on those emulated servers with hacks. Compared to Sony server were use of MacroQuest is a given to almost the entire population.
-
@Dashrender said:
Now, does this mean to stop using Open Source code, no of course not. Just be aware.
You need to be aware of ALL software, but Open Source the least. Every concern you have with open source you also have with closed source, plus more. The logic is that simple. Open source introduces no risk from being open but eliminates many and encourages better practice. Closed source literally introduces some types of risks and encourages others.
So yes, you need to be aware. But stating it like this is misleading. You need to be less aware.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But the reality is that the code is rarely audited.
Again, you are looking for perfect. Rarely audited is still better than never audited.
I'd argue this point at this time. If you really want to find something to exploit, you might have an easier time with it today in the sea of Open Source software (again I point to OpenSSL). Who knows how long the NSA knew about that problem and just didn't report it, and why did they know - it's just as likely that they stumbled upon it as it is that they scoured over the code and found it.
You would argue it based on what reasoning? Pointing to OpenSSL means nothing. Like I said, that case showed how good open source was, not what you are implying. Also it is an anecdote and means nothing, literally nothing. We find issues like this is closed source too, every day. But you aren't pointing to those, only to OpenSSL, why?
-
@coliver said:
@Dashrender said:
@scottalanmiller said:
I think the biggest threat is the oversight of the code rather than the technology approach. If security is the top concern then the open source aspect of Xen is a big deal for security. Far more important than PV vs FV.
Traditionally I'd agree with you. But the reality is that the code is rarely audited. How long was that bug in OpenSSL before it was discovered? A decade, wasn't it?
If I remember correctly a lot of open source companies (ones that sell support) actually have bug bounties where you can be paid for finding bugs in the open source software. As opposed to certain closed source vendors who have threatened lawsuits against people who reveal vulnerabilities.
Yes, it is very common for there to be bug and security bounties, not just from the groups that make the code but also from companies that use it.
