Message ID | 20231220151358.2147066-1-nikunj@amd.com (mailing list archive) |
---|---|
Headers | show |
Series | Add Secure TSC support for SNP guests | expand |
On 12/20/2023 8:43 PM, Nikunj A Dadhania wrote: > Secure TSC allows guests to securely use RDTSC/RDTSCP instructions as the > parameters being used cannot be changed by hypervisor once the guest is > launched. More details in the AMD64 APM Vol 2, Section "Secure TSC". > > During the boot-up of the secondary cpus, SecureTSC enabled guests need to > query TSC info from AMD Security Processor. This communication channel is > encrypted between the AMD Security Processor and the guest, the hypervisor > is just the conduit to deliver the guest messages to the AMD Security > Processor. Each message is protected with an AEAD (AES-256 GCM). See "SEV > Secure Nested Paging Firmware ABI Specification" document (currently at > https://www.amd.com/system/files/TechDocs/56860.pdf) section "TSC Info" > > Use a minimal GCM library to encrypt/decrypt SNP Guest messages to > communicate with the AMD Security Processor which is available at early > boot. > > SEV-guest driver has the implementation for guest and AMD Security > Processor communication. As the TSC_INFO needs to be initialized during > early boot before smp cpus are started, move most of the sev-guest driver > code to kernel/sev.c and provide well defined APIs to the sev-guest driver > to use the interface to avoid code-duplication. > > Patches: > 01-08: Preparation and movement of sev-guest driver code > 09-16: SecureTSC enablement patches. > > Testing SecureTSC > ----------------- > > SecureTSC hypervisor patches based on top of SEV-SNP Guest MEMFD series: > https://github.com/nikunjad/linux/tree/snp-host-latest-securetsc_v5 > > QEMU changes: > https://github.com/nikunjad/qemu/tree/snp_securetsc_v5 > > QEMU commandline SEV-SNP-UPM with SecureTSC: > > qemu-system-x86_64 -cpu EPYC-Milan-v2,+secure-tsc,+invtsc -smp 4 \ > -object memory-backend-memfd-private,id=ram1,size=1G,share=true \ > -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on \ > -machine q35,confidential-guest-support=sev0,memory-backend=ram1,kvm-type=snp \ > ... > > Changelog: > ---------- > v7: > * Drop mutex from the snp_dev and add snp_guest_cmd_{lock,unlock} API > * Added comments for secrets page failure > * Added define for maximum supported VMPCK > * Updated comments why sev_status is used directly instead of > cpu_feature_enabled() A gentle reminder. Regards Nikunj
On Wed, Jan 24, 2024 at 10:08 PM Nikunj A. Dadhania <nikunj@amd.com> wrote: > > On 12/20/2023 8:43 PM, Nikunj A Dadhania wrote: > > Secure TSC allows guests to securely use RDTSC/RDTSCP instructions as the > > parameters being used cannot be changed by hypervisor once the guest is > > launched. More details in the AMD64 APM Vol 2, Section "Secure TSC". > > > > During the boot-up of the secondary cpus, SecureTSC enabled guests need to > > query TSC info from AMD Security Processor. This communication channel is > > encrypted between the AMD Security Processor and the guest, the hypervisor > > is just the conduit to deliver the guest messages to the AMD Security > > Processor. Each message is protected with an AEAD (AES-256 GCM). See "SEV > > Secure Nested Paging Firmware ABI Specification" document (currently at > > https://www.amd.com/system/files/TechDocs/56860.pdf) section "TSC Info" > > > > Use a minimal GCM library to encrypt/decrypt SNP Guest messages to > > communicate with the AMD Security Processor which is available at early > > boot. > > > > SEV-guest driver has the implementation for guest and AMD Security > > Processor communication. As the TSC_INFO needs to be initialized during > > early boot before smp cpus are started, move most of the sev-guest driver > > code to kernel/sev.c and provide well defined APIs to the sev-guest driver > > to use the interface to avoid code-duplication. > > > > Patches: > > 01-08: Preparation and movement of sev-guest driver code > > 09-16: SecureTSC enablement patches. > > > > Testing SecureTSC > > ----------------- > > > > SecureTSC hypervisor patches based on top of SEV-SNP Guest MEMFD series: > > https://github.com/nikunjad/linux/tree/snp-host-latest-securetsc_v5 > > > > QEMU changes: > > https://github.com/nikunjad/qemu/tree/snp_securetsc_v5 > > > > QEMU commandline SEV-SNP-UPM with SecureTSC: > > > > qemu-system-x86_64 -cpu EPYC-Milan-v2,+secure-tsc,+invtsc -smp 4 \ > > -object memory-backend-memfd-private,id=ram1,size=1G,share=true \ > > -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on \ > > -machine q35,confidential-guest-support=sev0,memory-backend=ram1,kvm-type=snp \ > > ... > > > > Changelog: > > ---------- > > v7: > > * Drop mutex from the snp_dev and add snp_guest_cmd_{lock,unlock} API > > * Added comments for secrets page failure > > * Added define for maximum supported VMPCK > > * Updated comments why sev_status is used directly instead of > > cpu_feature_enabled() > > A gentle reminder. > From the Google testing side of things, we may not get to this for another while. > Regards > Nikunj >
On 1/26/2024 6:30 AM, Dionna Amalie Glaze wrote: > On Wed, Jan 24, 2024 at 10:08 PM Nikunj A. Dadhania <nikunj@amd.com> wrote: >> >> On 12/20/2023 8:43 PM, Nikunj A Dadhania wrote: >>> Secure TSC allows guests to securely use RDTSC/RDTSCP instructions as the >>> parameters being used cannot be changed by hypervisor once the guest is >>> launched. More details in the AMD64 APM Vol 2, Section "Secure TSC". >>> >>> During the boot-up of the secondary cpus, SecureTSC enabled guests need to >>> query TSC info from AMD Security Processor. This communication channel is >>> encrypted between the AMD Security Processor and the guest, the hypervisor >>> is just the conduit to deliver the guest messages to the AMD Security >>> Processor. Each message is protected with an AEAD (AES-256 GCM). See "SEV >>> Secure Nested Paging Firmware ABI Specification" document (currently at >>> https://www.amd.com/system/files/TechDocs/56860.pdf) section "TSC Info" >>> >>> Use a minimal GCM library to encrypt/decrypt SNP Guest messages to >>> communicate with the AMD Security Processor which is available at early >>> boot. >>> >>> SEV-guest driver has the implementation for guest and AMD Security >>> Processor communication. As the TSC_INFO needs to be initialized during >>> early boot before smp cpus are started, move most of the sev-guest driver >>> code to kernel/sev.c and provide well defined APIs to the sev-guest driver >>> to use the interface to avoid code-duplication. >>> >>> Patches: >>> 01-08: Preparation and movement of sev-guest driver code >>> 09-16: SecureTSC enablement patches. >>> >>> Testing SecureTSC >>> ----------------- >>> >>> SecureTSC hypervisor patches based on top of SEV-SNP Guest MEMFD series: >>> https://github.com/nikunjad/linux/tree/snp-host-latest-securetsc_v5 >>> >>> QEMU changes: >>> https://github.com/nikunjad/qemu/tree/snp_securetsc_v5 >>> >>> QEMU commandline SEV-SNP-UPM with SecureTSC: >>> >>> qemu-system-x86_64 -cpu EPYC-Milan-v2,+secure-tsc,+invtsc -smp 4 \ >>> -object memory-backend-memfd-private,id=ram1,size=1G,share=true \ >>> -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on \ >>> -machine q35,confidential-guest-support=sev0,memory-backend=ram1,kvm-type=snp \ >>> ... >>> >>> Changelog: >>> ---------- >>> v7: >>> * Drop mutex from the snp_dev and add snp_guest_cmd_{lock,unlock} API >>> * Added comments for secrets page failure >>> * Added define for maximum supported VMPCK >>> * Updated comments why sev_status is used directly instead of >>> cpu_feature_enabled() I missed this in the change log: * Added Tested-by from Peter Gonda (https://lore.kernel.org/lkml/CAMkAt6pULjLVUO6Ys4Sq1a79d93_5w5URgLYNXY-aW2jSemruA@mail.gmail.com/) >> >> A gentle reminder. >> > > From the Google testing side of things, we may not get to this for > another while. Thanks Dionna Regards Nikunj