Hypervisor headaches: Hosts hosed by x86 exception bugs Various hypervisors and operating systems are scrambling to patch around an x86 bug that lets an admin-level guest crash the underlying CPU, causing a denial-of-service to anyone else on the same machine. The issue, described here, is that with some x86 CPUs, an attacker with kernel-mode code execution privileges on a guest …
It affects every hypervisor. It's a bug in the CPU. The patches Xen etc are pushing out is a software workaround. If you read their notes on the xen patch they basically say "this should be fixed in the cpu but that's a bit unreasonable because the cpu is hardware* so we are putting a software workaround in place"
*maybe the issue can be fixed in a microcode update?
So there is a bug in some CPU's virtualisation support. The Register runs a story on it. Great...
But we get very little real info, just hype. Is it just x86? and not x64? in which case this is a non-story, as any significant user of virtualisation will be doing it on 64 bit servers. The issue 'described here' link actually takes you to the Microsoft patch, which is not exactly informative of the problem.
Please reflect on how a more suitable article could have been written.
In fairness, the two CVEs are both content-free and MS have not publicly disclosed the bugs yet. The Xen bug report suggests that the problems lie with the delivery of exceptions to 32-bit guests and so perhaps the host bitness wouldn't matter. The MS report states that the problem is with the chipset, not the CPU, but is otherwise (as you note) not exactly informative.
A "more suitable article" probably can't be written right now unless you are willing to reverse engineer the patches.
"Xen bug report suggests that the problems lie with the delivery of exceptions to 32-bit guests"
Plausible, and it wouldn't be the first such bug.
Search for Intel errata AAK167 and BT248 from 2013.
Can I remind of F00F bug from nineties, too? No? OK then. Coat, please.
You only need to worry about this if you run a malicious guest, or a guest that has been compromised by malware with supervisory level access. In either case, it is possible for the rogue code to set up the necessary environment to exploit these design flaws.
Hard to say, until there's more info on it.
2013 batch (AAK167/BD132/BT248) definitely made ESX turn purple at face.
Can't remember if VMware ever tried to apply CPU microcode patches via kernel updates. Anyhow, in 2013 IT folks ran around like Duracell bunnies, doing BIOS updates for every ESX and Hyper-V server out there.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
