Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xen hypervisor memory corruption due to x86 emulator flaw

xenbits.xen.org

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#31

Post by avsm »

It's worth noting that most of these bugs are right in the innards of the x86 emulation. Xen/ARM is a breath of fresh air, since they took the decision to only support the new ARMv7 virtualization extensions. This eliminate the need for qemu running in dom0 per VM and the instruction emulation plumbing.

We've got a distribution of Xen 4.4/ARMv7/ubuntu for anyone curious to try it out on a cheapo Cubieboard2 or Cubietruck over at https://github.com/mirage/xen-arm-builder (with prebuilt SDcard images at http://blobs.openmirage.org)

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#32

Post by avsm »

peterwwillis wrote: post #8
amyjess wrote: post #4

Well, guess my Linode's getting rebooted again.

If they have one spare xen host they can live migrate all guests from one host to the spare, patch the original host, reboot, then live migrate the spare's guests back to the original, and repeat. Patching them all and rebooting them all at once might be quicker though.

The XenServer toolstack supports exactly this mode of operation in a pool of physical hosts via a 'host evacuate' operation that live relocates VMs away and brings them back once the host upgrade is complete.

http://docs.vmd.citrix.com/XenServer/5.0.0/1.0/en_gb/install...

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#34

Post by weland »

kyboren wrote: post #3

This 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…

de Raadt's remarks about virtualization do spring up in my mind.

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#35

Post by mrmondo »

fwilhelm wrote: post #9

I 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 post, thanks. By the way your site seems very slow to load in Australia - it might benefit from use of a CDN if you don't already use one. (I usually recommend Cloudflare to people, their free service is great)

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#36

Post by peterwwillis »

ambrop7 wrote: post #33

Stupid question: Why does Xen need to emulate x86?

tl;dr, Windows. But also various limitations of how PV or HVM hosts work.

PVH fixes it so you don't need emulation in Linux, but it's a brand new feature and probably not production quality. Read this (it's not too technical) http://wiki.xen.org/wiki/Virtualization_Spectrum

As of this writing, Xen 4.4 and Linux 3.14 have experimental support for PVH DomUs and Xen 4.5 has support for PVH Dom0s. PVH allows practically native-hardware-speed guests without any emulation.

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#37

Post by rbanffy »

Someone1234 wrote: post #29
Alupis wrote: post #28

Earlier 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. > 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…

> C/C++ starts you in a position where it is extremely easy to write insecure code.

It's worth mentioning K&R, which used to be where people learn C, has a huge number of instances of very risky practices.

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#38

Post by cthalupa »

detaro wrote: post #24
zokier wrote: post #19

Earlier 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?

(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 Xe…

>And I think Xen is better at isolating drivers

Xen allows for creating an entire stub domU solely for running the driver, then giving a running guest access via ring buffer in a shared memory segment.

(So, yep, you're correct in your thinking)

Re: Xen hypervisor memory corruption due to x86 emulator flaw

#39

Post by cthalupa »

peterwwillis wrote: post #36
ambrop7 wrote: post #33

Stupid question: Why does Xen need to emulate x86?

tl;dr, Windows. But also various limitations of how PV or HVM hosts work. PVH fixes it so you don't need emulation in Linux, but it's a brand new feature and probably not production quality. Read this (it's not too technical) http://wiki.xen.org/wiki/Virtualization_Spectrum As of this writing, Xen 4.4 and Linux 3.14 have experimental support for PVH DomUs and Xen 4.5 has support for PVH Dom0s. PVH allows practically…

Completely eliminating emulation isn't always desirable, unfortunately. The problem with PVH is the forcing the use of event channels to deliver interrupts.

Local APIC emulation is fully accelerated on modern processors, which is a big win for any use case that is heavy on interrupts.

Post reply on HN