| Message ID | 20210709215550.32496-1-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add AMD Secure Nested Paging (SEV-SNP) support | expand |
On 7/9/21 4:55 PM, Brijesh Singh wrote: > SEV-SNP builds upon existing SEV and SEV-ES functionality while adding > new hardware-based memory protections. SEV-SNP adds strong memory integrity > protection to help prevent malicious hypervisor-based attacks like data > replay, memory re-mapping and more in order to create an isolated memory > encryption environment. > > The patches to support the SEV-SNP in Linux kernel and OVMF are available: > https://lore.kernel.org/kvm/20210707181506.30489-1-brijesh.singh@amd.com/ > https://lore.kernel.org/kvm/20210707183616.5620-1-brijesh.singh@amd.com/ > https://edk2.groups.io/g/devel/message/77335?p=,,,20,0,0,0::Created,,posterid%3A5969970,20,2,20,83891508 > > The Qemu patches uses the command id added by the SEV-SNP hypervisor > patches to bootstrap the SEV-SNP VMs. > > TODO: > * Add support to filter CPUID values through the PSP. > > Additional resources > --------------------- > SEV-SNP whitepaper > https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf > > APM 2: https://www.amd.com/system/files/TechDocs/24593.pdf (section 15.36) > > GHCB spec: > https://developer.amd.com/wp-content/resources/56421.pdf > > SEV-SNP firmware specification: > https://www.amd.com/system/files/TechDocs/56860.pdf > > Brijesh Singh (6): > linux-header: add the SNP specific command > i386/sev: extend sev-guest property to include SEV-SNP > i386/sev: initialize SNP context > i386/sev: add the SNP launch start context > i386/sev: add support to encrypt BIOS when SEV-SNP is enabled > i386/sev: populate secrets and cpuid page and finalize the SNP launch > > docs/amd-memory-encryption.txt | 81 +++++- > linux-headers/linux/kvm.h | 47 ++++ > qapi/qom.json | 6 + > target/i386/sev.c | 498 ++++++++++++++++++++++++++++++++- > target/i386/sev_i386.h | 1 + > target/i386/trace-events | 4 + > 6 files changed, 628 insertions(+), 9 deletions(-) Don't forget to update target/i386/sev-stub.c as appropriate, too. Thanks, Tom >
Brijesh, On 10/07/2021 0:55, Brijesh Singh wrote: > SEV-SNP builds upon existing SEV and SEV-ES functionality while adding > new hardware-based memory protections. SEV-SNP adds strong memory integrity > protection to help prevent malicious hypervisor-based attacks like data > replay, memory re-mapping and more in order to create an isolated memory > encryption environment. > > The patches to support the SEV-SNP in Linux kernel and OVMF are available: > https://lore.kernel.org/kvm/20210707181506.30489-1-brijesh.singh@amd.com/ > https://lore.kernel.org/kvm/20210707183616.5620-1-brijesh.singh@amd.com/ > https://edk2.groups.io/g/devel/message/77335?p=,,,20,0,0,0::Created,,posterid%3A5969970,20,2,20,83891508 > > The Qemu patches uses the command id added by the SEV-SNP hypervisor > patches to bootstrap the SEV-SNP VMs. > > TODO: > * Add support to filter CPUID values through the PSP. > > Additional resources > --------------------- > SEV-SNP whitepaper > https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf > > APM 2: https://www.amd.com/system/files/TechDocs/24593.pdf (section 15.36) > > GHCB spec: > https://developer.amd.com/wp-content/resources/56421.pdf > > SEV-SNP firmware specification: > https://www.amd.com/system/files/TechDocs/56860.pdf > > Brijesh Singh (6): > linux-header: add the SNP specific command > i386/sev: extend sev-guest property to include SEV-SNP > i386/sev: initialize SNP context > i386/sev: add the SNP launch start context > i386/sev: add support to encrypt BIOS when SEV-SNP is enabled > i386/sev: populate secrets and cpuid page and finalize the SNP launch > > docs/amd-memory-encryption.txt | 81 +++++- > linux-headers/linux/kvm.h | 47 ++++ > qapi/qom.json | 6 + > target/i386/sev.c | 498 ++++++++++++++++++++++++++++++++- > target/i386/sev_i386.h | 1 + > target/i386/trace-events | 4 + > 6 files changed, 628 insertions(+), 9 deletions(-) > It might be useful to allow the user to view SNP-related status/settings in HMP's `info sev` and QMP's qom-list/qom-get under /machine/confidential-guest-support . (Not sure whether HMP is deprecated and new stuff should not be added there.) Particularly confusing is the `policy` attribute which is only relevant for SEV / SEV-ES, while there's a new `snp.policy` attribute for SNP... Maybe the irrelevant attributes should not be added to the tree when not in SNP. -Dov
* Dov Murik (dovmurik@linux.ibm.com) wrote: > Brijesh, > > On 10/07/2021 0:55, Brijesh Singh wrote: > > SEV-SNP builds upon existing SEV and SEV-ES functionality while adding > > new hardware-based memory protections. SEV-SNP adds strong memory integrity > > protection to help prevent malicious hypervisor-based attacks like data > > replay, memory re-mapping and more in order to create an isolated memory > > encryption environment. > > > > The patches to support the SEV-SNP in Linux kernel and OVMF are available: > > https://lore.kernel.org/kvm/20210707181506.30489-1-brijesh.singh@amd.com/ > > https://lore.kernel.org/kvm/20210707183616.5620-1-brijesh.singh@amd.com/ > > https://edk2.groups.io/g/devel/message/77335?p=,,,20,0,0,0::Created,,posterid%3A5969970,20,2,20,83891508 > > > > The Qemu patches uses the command id added by the SEV-SNP hypervisor > > patches to bootstrap the SEV-SNP VMs. > > > > TODO: > > * Add support to filter CPUID values through the PSP. > > > > Additional resources > > --------------------- > > SEV-SNP whitepaper > > https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf > > > > APM 2: https://www.amd.com/system/files/TechDocs/24593.pdf (section 15.36) > > > > GHCB spec: > > https://developer.amd.com/wp-content/resources/56421.pdf > > > > SEV-SNP firmware specification: > > https://www.amd.com/system/files/TechDocs/56860.pdf > > > > Brijesh Singh (6): > > linux-header: add the SNP specific command > > i386/sev: extend sev-guest property to include SEV-SNP > > i386/sev: initialize SNP context > > i386/sev: add the SNP launch start context > > i386/sev: add support to encrypt BIOS when SEV-SNP is enabled > > i386/sev: populate secrets and cpuid page and finalize the SNP launch > > > > docs/amd-memory-encryption.txt | 81 +++++- > > linux-headers/linux/kvm.h | 47 ++++ > > qapi/qom.json | 6 + > > target/i386/sev.c | 498 ++++++++++++++++++++++++++++++++- > > target/i386/sev_i386.h | 1 + > > target/i386/trace-events | 4 + > > 6 files changed, 628 insertions(+), 9 deletions(-) > > > > It might be useful to allow the user to view SNP-related status/settings > in HMP's `info sev` and QMP's qom-list/qom-get under > /machine/confidential-guest-support . > > (Not sure whether HMP is deprecated and new stuff should not be added > there.) It's still fine to add stuff to HMP, although generally you should be adding it to QMP as well (unles sit's purely for debug and may change). Dave > Particularly confusing is the `policy` attribute which is only relevant > for SEV / SEV-ES, while there's a new `snp.policy` attribute for SNP... > Maybe the irrelevant attributes should not be added to the tree when not > in SNP. > > -Dov >
On 7/13/21 3:31 AM, Dr. David Alan Gilbert wrote:
> adding it to QMP as well (unles sit's purely for debug and may change).
We have query-sev QMP, I will extend to add a new 'snp: bool' field.
thanks
On 7/13/21 3:05 AM, Dov Murik wrote:> > Particularly confusing is the `policy` attribute which is only relevant > for SEV / SEV-ES, while there's a new `snp.policy` attribute for SNP... > Maybe the irrelevant attributes should not be added to the tree when not > in SNP. The policy fields are also applicable to the SNP. The main difference are: - in SEV/SEV-ES the policy is 32-bit compare to 64-bit value in SEV-SNP. However, for SEV-SNP spec uses lower 32-bit value and higher bits are marked reserved. - the bit field meaning are different Based on this, we can introduce a new filed 'snp-policy'. -Brijesh
* Brijesh Singh (brijesh.singh@amd.com) wrote: > > > On 7/13/21 3:05 AM, Dov Murik wrote:> > > Particularly confusing is the `policy` attribute which is only relevant > > for SEV / SEV-ES, while there's a new `snp.policy` attribute for SNP... > > Maybe the irrelevant attributes should not be added to the tree when not > > in SNP. > > The policy fields are also applicable to the SNP. The main difference are: > > - in SEV/SEV-ES the policy is 32-bit compare to 64-bit value in SEV-SNP. > However, for SEV-SNP spec uses lower 32-bit value and higher bits are marked > reserved. > > - the bit field meaning are different Ah, I see that from the SNP ABI spec (section 4.3). That's a bit subtle; in that at the moment we select SEV or SEV-ES based on the existing guest policy flags; I think you're saying that SEV-SNP is enabled by the user explicitly. > Based on this, we can introduce a new filed 'snp-policy'. Yes, people are bound to confuse them if they're not clearly separated; although I guess whatever comes after SNP will probably share that longer field? Dave > -Brijesh >
On 7/14/21 4:52 AM, Dr. David Alan Gilbert wrote: > * Brijesh Singh (brijesh.singh@amd.com) wrote: >> >> On 7/13/21 3:05 AM, Dov Murik wrote:> >>> Particularly confusing is the `policy` attribute which is only relevant >>> for SEV / SEV-ES, while there's a new `snp.policy` attribute for SNP... >>> Maybe the irrelevant attributes should not be added to the tree when not >>> in SNP. >> The policy fields are also applicable to the SNP. The main difference are: >> >> - in SEV/SEV-ES the policy is 32-bit compare to 64-bit value in SEV-SNP. >> However, for SEV-SNP spec uses lower 32-bit value and higher bits are marked >> reserved. >> >> - the bit field meaning are different > Ah, I see that from the SNP ABI spec (section 4.3). > > That's a bit subtle; in that at the moment we select SEV or SEV-ES based > on the existing guest policy flags; I think you're saying that SEV-SNP > is enabled by the user explicitly. Correct. This is one of the reason that I added the "snp" property. > >> Based on this, we can introduce a new filed 'snp-policy'. > Yes, people are bound to confuse them if they're not clearly separated; > although I guess whatever comes after SNP will probably share that > longer field? I am keeping my finger crossed on it. I hope that in future they will share it. -Brijesh