Add SEV getting started guide for users#171
Add SEV getting started guide for users#171LakshmiSaiHarika wants to merge 1 commit intoAMDEPYC:mainfrom
Conversation
DGonzalezVillal
left a comment
DGonzalezVillal
left a comment
There was a problem hiding this comment.
I think the guide could use a bit more clarity around its main intention.
From my perspective, the goal of this guide should be to quickly introduce SEV and provide concise setup instructions for SNP. I emphasize SNP because that’s the feature we want users to focus on adopting, so it’s probably not necessary to go too deep into SEV-specific details.
I added some suggestions to help improve the organization of the guide and narrow its scope a bit. I think it’s meant for users who want to start using SNP but may not know how to get started.
One additional note — for users who simply want to use SNP (not certify an OS), we probably shouldn’t direct them to use the artifacts from this repository. Instead, they should check which operating systems we’ve already certified and then download the official releases for their hosts or guests. The images in this repo are minimized and slightly modified versions of the official ones, so they’re not intended for real production environments.
Signed-off-by: Harika Nittala <lnittala@amd.com> Doc enhancements as per Diego's suggestion Signed-off-by: Harika Nittala <lnittala@amd.com>
LakshmiSaiHarika
force-pushed
the
getting-started-user-guide
branch
from
bdc67fa to
83a6dea
Compare
DGonzalezVillal
left a comment
DGonzalezVillal
left a comment
There was a problem hiding this comment.
Just a couple of more things, mostly wordking. the rest of it looks good thanks !
| # Enabling AMD Security Features in AMD EPYC Processors | ||
|
|
||
| ## SEV Introduction | ||
| When a virtual machine (VM) starts, data is loaded into system memory (RAM). The data can be vulnerable to software or hardware probing by attackers on the host system- especially in shared environments like cloud platforms, where multiple tenants share the same physical resources. To mitigate this risk, users must ensure that the data in RAM is protected from both attackers and hypervisors. Doing so reduces the level of trust that virtual machines need to place in the hypervisor and the host system's administrators. |
There was a problem hiding this comment.
| When a virtual machine (VM) starts, data is loaded into system memory (RAM). The data can be vulnerable to software or hardware probing by attackers on the host system- especially in shared environments like cloud platforms, where multiple tenants share the same physical resources. To mitigate this risk, users must ensure that the data in RAM is protected from both attackers and hypervisors. Doing so reduces the level of trust that virtual machines need to place in the hypervisor and the host system's administrators. | |
| When a virtual machine (VM) starts, data is loaded into system memory (RAM). The data can be vulnerable to software or hardware probing by attackers on the host system- especially in shared environments like cloud platforms, where multiple tenants share the same physical resources. To mitigate this risk, users must ensure that the data in-use is protected from both attackers and malicious hypervisors. Doing so reduces the level of trust that virtual machines need to place in the hypervisor and the host system's administrators. |
|
|
||
| AMD EPYC processors introduce confidential computing technologies that provide memory encryption for virtualized environments, protecting data not only from physical attacks but also from other virtual machines and even the hypervisor itself. | ||
|
|
||
| The following sections describe the different generations of Secure Encrypted Virtualization (SEV), each building on the previous generation and introducing new security capabilities and features: |
There was a problem hiding this comment.
| The following sections describe the different generations of Secure Encrypted Virtualization (SEV), each building on the previous generation and introducing new security capabilities and features: | |
| There are currently 3 different generations of SEV, each building on the previous generation and introducing new security capabilities and features: |
|
|
||
| The following sections describe the different generations of Secure Encrypted Virtualization (SEV), each building on the previous generation and introducing new security capabilities and features: | ||
|
|
||
| **SEV (Secure Encrypted Virtualization)** is the first generation of the security features. It protects KVM virtual machines (VMs) by transparently encrypting the memory of the VM using a unique key. |
There was a problem hiding this comment.
| **SEV (Secure Encrypted Virtualization)** is the first generation of the security features. It protects KVM virtual machines (VMs) by transparently encrypting the memory of the VM using a unique key. | |
| **Legacy SEV (Secure Encrypted Virtualization)** is the first generation of the security features. It protects KVM virtual machines (VMs) by transparently encrypting the memory of the VM using a unique key. |
I think we decided to refer to the technology as a whole as SEV and when we are referring to the first generation we are referring to it as Legacy SEV.
| $ qemu-system-x86_64 \ | ||
| -enable-kvm \ | ||
| -machine q35 \ | ||
| -cpu EPYC-v4 \ | ||
| -machine memory-encryption=sev0 \ | ||
| -monitor none \ | ||
| -display none \ | ||
| -object memory-backend-memfd,id=ram1,size=<guest-ram-size> \ | ||
| -machine memory-backend=ram1 \ | ||
| -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 kernel-hashes=on \ | ||
| -bios <amdsev-ovmf-path> \ | ||
| -hda <path-to-guest-image> | ||
| ``` | ||
| Users may allocate the desired amount of memory for the guest virtual machine, with a minimum requirement of 2 GB (2048 MB). | ||
|
|
||
| `amdsev-ovmf-path` refers to the AMDSEV UEFI compatible guest firmware located at either `/usr/share/ovmf/OVMF.amdsev.fd` or `/usr/share/edk2/ovmf/OVMF.amdsev.fd` based on your host linux distribution. | ||
|
|
||
| `path-to-guest-image` refers to your custom guest image file path. |
There was a problem hiding this comment.
I would add more information on the -object sev-snp-guest command and the difference between this object and the legacy sev command.
Also if people use the -m flag in qemu, that needs to match whatever is in the memory-backend-memfd line. I think that should be made clear too.
2 participants
Created an easy-to-use Getting Started SEV guides for different users: