This one exploit "shadow MMU" in the nested virtualization path of KVM, so this one is more-limited than EPT/NPT vul'n (KVM defaults to EPT/NPT, nested virt'n is disabled by default).
Nested virtualization is rather a niche feature, and, tbh, considering that shadow MMU is highly complicated legacy code (i.e. outside of the main happy path) and has been source of critical vul'n, I would avoid nested virtualization on KVM.
Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this?
(To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)
8 comments
[ 4.1 ms ] story [ 31.8 ms ] threadPatch Thursday for cloud VM ppl lol
Nested virtualization is rather a niche feature, and, tbh, considering that shadow MMU is highly complicated legacy code (i.e. outside of the main happy path) and has been source of critical vul'n, I would avoid nested virtualization on KVM.
(This comment is a reference to https://youtu.be/v1Mfirg2-Z8
(To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)
[That did work around Januscape: https://news.ycombinator.com/item?id=48815819]
VMM handles all VM exceptions, and is just another user program. It has no higher capabilities than the VM itself.
> A: Yes. I recommend establishing a sustainable patching process for host hypervisors. Winter is coming.