Rafal Wojtczuk has discovered a vulnerability which can allow a 64-bit
PV guest kernel running on a 64-bit hypervisor to escalate privileges
to that of the host by arranging for a system call to return via
sysret to a non-canonical RIP. Intel CPUs deliver the resulting
exception in an undesirable processor state.

IMPACT
======

Guest administrators can gain control of the host.

Depending on the particular guest kernel it is also possible that
non-privileged guest user processes can also elevate their privileges
to that of the host.

Systems using AMD CPUs are not vulnerable to this privilege
escalation. AMD have issued the following statement:
AMD processors’ SYSRET behavior is such that a non-canonical
address in RCX does not generate a #GP while in CPL0. We have
verified this with our architecture team, with our design team, and
have performed tests that verified this on silicon. Therefore, this
privilege escalation exposure is not applicable to any AMD
processor.

While investigating this, it was noted that some older AMD CPUs will
lock up under similar circumstances, causing a denial of service. See
XSA-9 for details.

MITIGATION
==========

This issue can be mitigated by running HVM (fully-virtualised)
or 32 bit PV guests only.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

These patches also resolve the issue described in XSA-8 (CVE-2012-0128).

Proxmox – VE has hit the 1.0 today! Without fail, I’d say this is the best combination of full system emulation, and logical partitioning available as of today. I have been playing with Xen on Solaris 10, and frankly it SHOULD have been better, but it’s been so much worse.

Although Solaris Zones, coupled with ZFS & Xen should be a clear winner, you’ll find out real quick that Zones do *NOT* easily allow for independant tcp/ip stacks (hope you have v3 nic drivers), the Xen networking again is a mess (v3 drivers anyone? Also those interfaces better be TCP/IP enabled on the host!) and get ready to edit the /var/lib/xend/domains directory files a LOT…. And be ready for gegrep fun. Afterall domain names like “0aa811ef-3bd0-9140-583f-d5e09f93658e” make life all the easier. I will say that Xen does use Qemu disk images so there is an easy ‘upgrade’ path to/from KVM (the linux hypervisor found in ProxmoxVE). What I don’t get is the massive disconnect between virsh & the xend process.

And if you are running Xen, the you’ll want SOME print documentation… I just wish I didn’t think it’d be that intuitive. So at least creating this:

(device (vif(bridge iprb0)(uuid c0e47a99-70e5-1ebe-44a4-54895cb24a15)(script vif-vnic)(mac 00:16:3e:56:df:81)(model ne2k_pci)(backend 0)))would have been easier.From my notes, how to tell if your nic is new enough to drive Xen/Zones: