Unmapped Private Memory for Confidential Guests
summary
Unmapped Private Memory (UPM) introduces a new private mem slot backed by a memfd-style MFD so KVM can program nested page tables from private guest pages without exposing host mappings; conversions use a KVM exit memory fault or a batched vmg-exit and require the VMM to allocate pages in the MFD and ioctl KVM to flip xarray state. Problems demonstrated: potential 2x memory accounting, a reported 3x slowdown for frequent flip/dealloc, and the need to split/restore the kernel direct map and handle racing host kernel accesses.
AI-written summary · about
chapters (12)
- 0:00Introduction to UPM
- 1:48Normal KVM slot recap
- 3:10Private memory slot implementation
- 5:17Implicit page state conversions
- 6:21Explicit page state conversions
- 7:08Pros and cons of UPM
- 8:33Memory allocation concerns
- 11:28Kernel direct map handling
- 13:58Batching page state changes
- 15:46Host access to shared memory
- 17:11Discussion on race conditions
- 19:44Q&A and closing
related talks
18mGuest Memory Protection -- Current Status and Future
50mProtected KVM on Arm64: A Technical Deep Dive
50mExporting Virtual Memory as dmabuf
16mTaming the Incoherent Cache Issue in Confidential VMs
30mRestricted Address Spaces for Container Security
28mConfidential Devices (TEE I/O): A series of modest proposals
28mProviding Confidential Guest Services with a Secure VM Service Module on AMD
28mNow You See Me, Now You Don't: Splitting pKVM Into Discrete, Mutually Exclusive Addr...