Rendered at 16:38:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
eqvinox 12 hours ago [-]
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.)
This one(Zapscape) exploits the same module(shadow MMU) as Januscape, so it does workaround the issue.
AFAIK the only code paths that activates shadow MMU are (1) lack of hardware EPT/NPT support (2) nested virtualization. Hiding `vmx`/`svm` prevents access to the second code path.
snvzz 5 hours ago [-]
In seL4, a VMM escape, hard as that'd be, yields nothing.
VMM handles all VM exceptions, and is just another user program. It has no higher capabilities than the VM itself.
minimaltom 23 hours ago [-]
Oh yay another one lol. This one seems much more general than the prior one that needed nested page tables.
Patch Thursday for cloud VM ppl lol
esjeon 15 hours ago [-]
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.
metadat 23 hours ago [-]
Do most cloud providers have live-migration or what is the approach to make this seamless? What kind of interruption might tenants notice?
cudder 23 hours ago [-]
It depends. If you have a plain old VM with no GPU and networked storage it's easy to migrate. If you're using low latency HW on the host it gets a lot trickier. Kuberenetes or some other fleet management helps there, you spin up new nodes and drain the old ones as capacity allows. If you have your PodDisruptionBudgets set right you won't notice much.
You can also use ksplice to live patch the vulnerable kernels as a first aid. I'm not an expert but I think there are some limits to what you can accomplish with it. Also guessing that the embargo period allows the big names to roll the patches out gradually enough that you won't see any panic shutdowns.
minimaltom 21 hours ago [-]
Yeah most cloud providers have live migration and a reasonably-well-tested playbook for updating the node kernel + hypervisor.
tryauuum 21 hours ago [-]
Doesn't this one need it as well? I see the shadow mmu
minimaltom 20 hours ago [-]
Right, but what x86 KVM setup is there in practice that doesnt present a mmu to its guest and hence keep its own track (shadow) of memory mappings?
Veserv 19 hours ago [-]
Shadow memory mappings are only needed when you do not have hardware virtualization or when doing nested virtualization.
From the page: "it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization"
That is not to say that it is not a serious vulnerability though.
rvz 24 hours ago [-]
Another serious critical vulnerability that almost no-one cares about, when they should.
inigyou 22 hours ago [-]
Every LLM bug in the Linux kernel (warehouse rave edit).
(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]
AFAIK the only code paths that activates shadow MMU are (1) lack of hardware EPT/NPT support (2) nested virtualization. Hiding `vmx`/`svm` prevents access to the second code path.
VMM handles all VM exceptions, and is just another user program. It has no higher capabilities than the VM itself.
Patch 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.
You can also use ksplice to live patch the vulnerable kernels as a first aid. I'm not an expert but I think there are some limits to what you can accomplish with it. Also guessing that the embargo period allows the big names to roll the patches out gradually enough that you won't see any panic shutdowns.
From the page: "it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization"
That is not to say that it is not a serious vulnerability though.
(This comment is a reference to https://youtu.be/v1Mfirg2-Z8