Hacker News Reader

Comment by rwmj | Hacker News Reader

QEMU/KVM on Fedora and RHEL uses seccomp, SELinux, namespaces and a separate user, and has done for about the past 5 years.

It's more interesting if they've managed to fully protect the kernel part of this (ie. vmm on OpenBSD, KVM on Linux) from the rest of the kernel.

View on HN

I'm not clear - do you want to protect the vmm driver in the host from attacks started by the rest of the host kernel? Or are you referring to attacks started by the guest on the http://man.openbsd.org/virtio.4 interface?

OpenBSD's VMs seem to be pledge()d to not call most host-side kernel interfaces...

I'm referring to a mistake in the kernel module corrupting some other in-kernel structures, especially if that can be triggered from guest code.

There is no privilege separation between kernel modules. They all run in the same address space with the same CPU privilege.

SELinux, seccomp, and all that protect a compromised user space thread in the host (responsible for running emulated guests, or one that provides virtual device support to guests) from other user space threads (other VMs). If there is a some problem in the KVM kernel module that stomps over memory, SELinux and seccomp can't do anything about it.

Right, exactly the point I made up-thread (https://news.ycombinator.com/item?id=12700045).

OpenBSD has no kernel modules, everything compiled into the GENERIC kernel is expected to be using proper kernel interfaces, mucking around with kernel structures is a no-no.

Nothing can really prevent driver bug causing a crash, this isn't a microkernel, but it can reduce exposure from userland, i.e: pledge restrictions on syscalls/ioctls/sysctls.

Reply on news.ycombinator.com