Trust, confidentiality, and hardening: the virtio lessons
summary
Virtio drivers get concrete hardening: core vring and device code are audited and now validate inputs (example: block driver rejects zero vring queues), and vdus uses software IOT bounce buffers plus kernel-provided file descriptors to isolate kernel memory. Confidential computing relies on memory encryption with integrity protection; untrusted virtio net uses TLS, block uses DM-Crypt+DM-Integrity but key placement and rollback risks remain. Remaining gaps include interrupt enable race, speculative execution barriers, and the need for per-device trust policy/attestation and management.
AI-written summary · about
chapters (13)
- 0:00Introduction to talk
- 1:03What is Vero standard
- 3:58Traditional virtualization trust model
- 6:52Linux vdus use case
- 12:32Hardening vdus drivers
- 14:39Hardware Vero devices
- 15:46Confidential Computing basics
- 21:07Untrusted devices in confidential VMs
- 26:02Open issues with Vero drivers
- 31:01Trusted devices with TDISP
- 33:11Need for user policy
- 36:00Conclusion and future work
- 36:41Q&A session
related talks
42mProtecting the Linux Kernel from Confidential Computing Threats in Virtual Environments
25mExploring I/O Support for Virtualization-Based Trusted Execution Environment
33mZephyr‑Based VIRTIO Backend on Xen: Toward Open Source Functional Safety
47mLinux Virtualization Based Security
34mVirtio-msg: Making Virtio Work Where It Does Not Today
41mTowards a Cross-Hypervisor Test Framework for VirtIO Backend Validation Using VirtIO...
28mConfidential Devices (TEE I/O): A series of modest proposals
19mSupporting Trusted Virtual Machines with Hardware-based Secure Remote Memory