Why is that Xen seems to have so many security issues compare to KVM?
More production use means more attention. Plenty of security issues everywhere.
In particular when you're developing in languages which are insecure by design.
Xen hypervisor memory corruption due to x86 emulator flaw
21–30 of 39 posts
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#22Earlier quoted context omitted.
Depends. My physical server isn't shared with anyone. Most local exploits are not a particular worry. A security vuln, almost by definition, requires a shared resource. No sharing, no caring.
That would depend on how "local" a "local exploit" is. If they require physical access to your system, well, then that's one thing. But if "local" is to mean on the network, that's far simpler for an attacker to pull off. > A security vuln, almost by definition, requires a shared resource. No sharing, no caring You would only not care if your servers have zero access to the internet and are air-gaped from the rest of…
"local" is generally understood to mean "not the network".
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#23This bug's existence and its patch have already made some worried. From the Qubes OS developers: [1] Additional thoughts by Qubes Security Team =========================================== We see several problems that concern us about this vulnerability and patching process: 1) It seems really difficult to understand why would anybody design a structure like the one shown above, which uses a union to store two, RADICA…
> We still believe Xen is currently the most secure hypervisor available, mostly because of its unique architecture features, that are lacking in any other product we are aware of. Does anyone know why KVM would be considered less secure than Xen?
My guess would be a couple of things: small Xen hypervisor vs potentially large Linux kernel, and driver domains. The latter involves putting each driver into its own domain (ie. Xen VM or process equivalent) and it means that bad drivers can do less damage to the rest of the system.
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#24This bug's existence and its patch have already made some worried. From the Qubes OS developers: [1] Additional thoughts by Qubes Security Team =========================================== We see several problems that concern us about this vulnerability and patching process: 1) It seems really difficult to understand why would anybody design a structure like the one shown above, which uses a union to store two, RADICA…
> We still believe Xen is currently the most secure hypervisor available, mostly because of its unique architecture features, that are lacking in any other product we are aware of. Does anyone know why KVM would be considered less secure than Xen?
(from memory, there are some design docs for Qubes OS floating around that discuss this) Xen is relatively small and contained, KVM sits on top of a full Linux kernel and potentially can access all of it, making it harder to tell what is accessible/exploitable and what is not. KVM also uses Qemu running as a process on the host linux for interfacing the VM, again exposing more potential attack surface. And I think Xen is better at isolating drivers, which for Qubes OS is a fundamental principle.
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#25Re: Xen hypervisor memory corruption due to x86 emulator flaw
#26Earlier quoted context omitted.
In particular when you're developing in languages which are insecure by design.
Insecure code can be written in any language.
Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages.
Nobody is proposing re-writing a hypervisor in Java or Python, but C/C++ isn't the only game in town anymore for unmanaged code, and the alternatives are designed from the ground up with security in mind.
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#27I wrote a blogpost with some more details about the bug, which you can find here: http://www.insinuator.net/2015/03/xen-xsa-123/
Interesting blog posts (it and the preceding one). It seems that reliably emulating the x86 architecture is made even harder by a few features not found in other popular architectures, like an extra level of indirection on memory access (segment registers and the corresponding segment overrides) and most instructions having a memory-accessing variant (instead of limiting memory access to separate "load" and "store" instructions, plus a few specialized atomic RMW instructions).
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#28Earlier quoted context omitted.
Insecure code can be written in any language.
Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages. Nobody is proposing re-writing a hypervisor in Java or Python, but C/C++ isn't the only game in town anymore for unmanaged code, and the alternatives are designed from the ground up with security in mind.
> Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages.
> and the alternatives are designed from the ground up with security in mind
The RMS Titanic was billed as one of the safest ships on the sea -- yet due to poorly implemented protocols and practices, negligent leadership, and disregard for best practices, it resulted in one of the most catastrophic maritime disasters.
Using the most "secure" programming language in the world, one can still design very insecure code. Conversely, using the most "insecure" programming language in the world, one can still design very secure code. This would boil down to the skill of the engineers, competence of leadership and adherence to best practices.
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#29Earlier quoted context omitted.
Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages. Nobody is proposing re-writing a hypervisor in Java or Python, but C/C++ isn't the only game in town anymore for unmanaged code, and the alternatives are designed from the ground up with security in mind.
> Just like any car can crash. However some cars are more dangerous than other cars, just as some programming languages are more likely to produce insecure code than other programming languages. > and the alternatives are designed from the ground up with security in mind The RMS Titanic was billed as one of the safest ships on the sea -- yet due to poorly implemented protocols and practices, negligent leadership, and…
The RMS Titanic sunk, but the engineers made it much harder to sink than ocean liners which preceded it.
C/C++ starts you in a position where it is extremely easy to write insecure code. Even a competent coder can produce insecure code in either language without a great deal of effort or stupidity on their part.
Other languages aren't "unsinkable" to come back to the Titanic, but they make it harder to sink, and the requirements on the developer aren't as high. Just like with the Titanic you have to hit the iceberg in a certain specific way to sink, rather than sinking from any old collision.
Certain C/C++ compilers have definitely made the situation better when in "strict mode" as well as a lot of tooling to identify potential problem points. However ultimately the language is plagued by "undefined behaviour" and a large code-base where developers are using various insecure tricks to save pennies (e.g. this exact exploit, where they are creating insecure code to save a single structure's worth of memory, which on an 8 GB stick of RAM is less than 1/2 of 1c worth (assuming $60/8 GB stick)).
Re: Xen hypervisor memory corruption due to x86 emulator flaw
#30Earlier quoted context omitted.
> We still believe Xen is currently the most secure hypervisor available, mostly because of its unique architecture features, that are lacking in any other product we are aware of. Does anyone know why KVM would be considered less secure than Xen?
My guess would be a couple of things: small Xen hypervisor vs potentially large Linux kernel, and driver domains. The latter involves putting each driver into its own domain (ie. Xen VM or process equivalent) and it means that bad drivers can do less damage to the rest of the system.
Sounds like Tanenbaum vs Torvalds redux..