AMD Publishes Latest SEV-SNP Guest + Hypervisor Support For Linux
AMD has published their fifth revision of SEV-SNP support for the KVM hypervisor and guest VM support for this Secure Encrypted Virtualization Secure Nested Paging functionality found with new EPYC 7003 series server processors.
SEV-SNP is the latest iteration of Secure Encrypted Virtualization. SEV-SNP provides additional memory integrity protections around replay protection, data corruption, memory aliasing, and memory re-mapping. There are also other hardware protections with SEV-SNP as outlined in the SEV comparison table:
While SEV-SNP support is found in EPYC 7003 series processors since their March debut, the Linux kernel bring-up for this latest functionality is still a work-in-progress. Shortly after the EPYC "Milan" announcement in March, the Linux kernel patches began and have now worked from their initial request-for-comments form to now a five rounds of code review for preparing the KVM hypervisor code and guest support for the latest SEV functionality.
On the hypervisor side are 45 patches that provide the basic building blocks for handling of SEV-SNP virtual machines. There still is though more security enhancements with SEV-SNP that aren't supported by this code, such as interrupt protection. Further feature work on SEV-SNP is expected after this initial base support lands.
With this v5 series there are many updates stemming from the prior rounds of code review, the ability to enforce a minimum SEV-SNP firmware version, and other low-level code improvements.
There are also the 38 patches providing the SEV-SNP guest support. That gets the initial support in place but like on the hypervisor side there still will be future feature work. As one example of future work, the guest support for now is also only doing pre-validation of memory pages rather than the on-demand/lazy validation -- Intel Linux engineers are currently working on similar code in this area around Linux "unaccepted memory" handling for that lazy/on-demand validation, which for their case is for TDX.
Like on the hypervisor side, the v5 guest patches are primarily for addressing comments raised during the prior code review.
It's getting very close to the Linux 5.15 merge window kicking off and not immediately clear if this code will prove to be ready for the next cycle whether these v5 patches have all issues addressed, but chances are given the timing the code will likely not be until at least Linux 5.16. Thus stretching it out from potentially appearing in autumn 2021 Linux distributions. We certainly hope the code will reach mainline in the next cycle or two so that this AMD SEV-SNP support can appear out-of-the-box in the default kernel of Ubuntu 22.04 LTS in the spring.
For out-of-tree kernel use, besides the patches on the kernel mailing list itself, AMD does continue to maintain the sev-snp-devel branch of AMDESE/AMDSEV on GitHub that some organizations are utilizing for SEV-SNP protections right now with EPYC Linux servers. Moving forward, hopefully AMD will manage to deliver more punctual upstream, mainlined kernel support for such features -- especially with AMD hiring more Linux engineers, including in the area of virtualization.
SEV-SNP is the latest iteration of Secure Encrypted Virtualization. SEV-SNP provides additional memory integrity protections around replay protection, data corruption, memory aliasing, and memory re-mapping. There are also other hardware protections with SEV-SNP as outlined in the SEV comparison table:
While SEV-SNP support is found in EPYC 7003 series processors since their March debut, the Linux kernel bring-up for this latest functionality is still a work-in-progress. Shortly after the EPYC "Milan" announcement in March, the Linux kernel patches began and have now worked from their initial request-for-comments form to now a five rounds of code review for preparing the KVM hypervisor code and guest support for the latest SEV functionality.
On the hypervisor side are 45 patches that provide the basic building blocks for handling of SEV-SNP virtual machines. There still is though more security enhancements with SEV-SNP that aren't supported by this code, such as interrupt protection. Further feature work on SEV-SNP is expected after this initial base support lands.
With this v5 series there are many updates stemming from the prior rounds of code review, the ability to enforce a minimum SEV-SNP firmware version, and other low-level code improvements.
There are also the 38 patches providing the SEV-SNP guest support. That gets the initial support in place but like on the hypervisor side there still will be future feature work. As one example of future work, the guest support for now is also only doing pre-validation of memory pages rather than the on-demand/lazy validation -- Intel Linux engineers are currently working on similar code in this area around Linux "unaccepted memory" handling for that lazy/on-demand validation, which for their case is for TDX.
Like on the hypervisor side, the v5 guest patches are primarily for addressing comments raised during the prior code review.
It's getting very close to the Linux 5.15 merge window kicking off and not immediately clear if this code will prove to be ready for the next cycle whether these v5 patches have all issues addressed, but chances are given the timing the code will likely not be until at least Linux 5.16. Thus stretching it out from potentially appearing in autumn 2021 Linux distributions. We certainly hope the code will reach mainline in the next cycle or two so that this AMD SEV-SNP support can appear out-of-the-box in the default kernel of Ubuntu 22.04 LTS in the spring.
For out-of-tree kernel use, besides the patches on the kernel mailing list itself, AMD does continue to maintain the sev-snp-devel branch of AMDESE/AMDSEV on GitHub that some organizations are utilizing for SEV-SNP protections right now with EPYC Linux servers. Moving forward, hopefully AMD will manage to deliver more punctual upstream, mainlined kernel support for such features -- especially with AMD hiring more Linux engineers, including in the area of virtualization.
Add A Comment