AMD SEV-SNP Hypervisor Support Nears The Mainline Linux Kernel

AMD's upstreaming effort around Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP) to the mainline Linux kernel appears to be nearly wrapped up with the latest hypervisor patches now at their fourteenth revision.

While AMD has maintained an out-of-tree kernel repository on GitHub with all of their latest SEV encryption bits for VMs, the effort of getting all of the SEV-SNP code into the mainline Linux kernel since the launch of the EPYC 7003 series has been quite a lengthy affair.

As written about last month on Phoronix, AMD With Upstream Linux Nears "The Ultimate Goal Of Confidential Computing". The x86 part of the SEV-SNP host support was added for the Linux 6.9 kernel but the KVM hypervisor patches weren't ready in time for this current kernel cycle.

During the Linux 6.9 merge window it was mentioned that the KVM hypervisor patches for SEV-SNP would hopefully be ready for the next cycle (v6.10) though it remains to be seen if definitively it will make it in time with the merge window opening in mid-May. But in any event on Sunday the 14th iteration of these hypervisor support patches were posted.

The [PATCH v14 00/22] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support patch series is now available for those interested in leveraging SEV-SNP for better securing virtual machines on AMD EPYC servers.

As explained in the patch cover letter though, some SEV-SNP features are still to be enabled later/separately:

"This part of the Secure Encrypted Paging (SEV-SNP) series focuses on the changes required to add KVM support for SEV-SNP. This series builds upon SEV-SNP guest support, which is now in mainline, and and SEV-SNP host initialization support, which is now in linux-next.

While series provides the basic building blocks to support booting the SEV-SNP VMs, it does not cover all the security enhancement introduced by the SEV-SNP such as interrupt protection, which will added in the future.

With SNP, when pages are marked as guest-owned in the RMP table, they are assigned to a specific guest/ASID, as well as a specific GFN with in the guest. Any attempts to map it in the RMP table to a different guest/ASID, or a different GFN within a guest/ASID, will result in an RMP nested page fault."

Here's to hopefully seeing this work wrap up soon for having a compelling upstreamed solution for securing VMs and embracing confidential computing.