The CoCo guest kernel can be attacked by the host/VMM through CoCo-specific hypercalls (to get values of PIO, MMIO, PCI config space, etc.) or shared memory communication interfaces. The static analysis of the kernel code has shown that the biggest users of such interfaces are device drivers (more than 95%). Every time a driver performs a PIO or MMIO reads (including reads from a pci config space), there is a possibility for a host/VMM to inject a malformed value.
Fortunately, only a small subset of device drivers are required for a typical CoCo guest operation (for Linux TDX SW reference stack it is a subset of virtio drivers described in VirtIO and shared memory), so most of the attack surface can be disabled by creating a small list of allowed device drivers. This is the main goal of the guest runtime device filter.
The CoCo guest kernel can be attacked by the host/VMM through CoCo-specific hypercalls (to get values of PIO, MMIO, PCI config space, etc.) or shared memory communication interfaces. The static analysis of the kernel code has shown that the biggest users of such interfaces are device drivers (more than 95%). Every time a driver performs a PIO or MMIO reads (including reads from a pci config space), there is a possibility for a host/VMM to inject a malformed value.
Fortunately, only a small subset of device drivers are required for a typical CoCo guest operation (for Linux TDX SW reference stack it is a subset of virtio drivers described in VirtIO and shared memory), so most of the attack surface can be disabled by creating a small list of allowed device drivers. This is the main goal of the guest runtime device filter.
The latest design for the device filter can be found in https://github.com/intel/tdx/commits/guest-device-filter