3 ms·
FirewallVM is probably "in front of" the untrusted NetVM. > we have code running in kernel mode It's 2020. You have to understand there are 3 levels now - hy
by tenebrisalietum 7y ago
FirewallVM is probably "in front of" the untrusted NetVM.
> we have code running in kernel mode
It's 2020. You have to understand there are 3 levels now - hypervisor, kernel, user, not two anymore. You don't necessarily own the system unless you are on hypervisor level. If you only do one thing in a VM, and don't rely too much OS primitives like users, etc. to do it (as you may not in a pure networking situation like routing, etc.), you can flatten kernel+user and increase performance and not sacrifice security.
That being said I should read this article and will do so.
- deleted 7y ago[deleted]
- blattimwind 7y agoThe real oops is that the boundary they are using as a trust boundary is not considered a trust boundary by its developers. Plainly, > the netback driver runs in dom0 and is fully trusted. It is coded to protect itself against misbehaving client VMs. Netfront, by contrast, assumes that netback is trustworthy. The Xen developers only considers bugs in netback to be security critical. > What can an attacker do once they’ve exploited FirewallVM’s trusting netfront driver? Presumably they now have complete control of FirewallVM. At this point, they can simply reuse the same exploit to take control of the client VMs, which are running the same trusting netfront code!