[v7,00/16] Add Secure TSC support for SNP guests

  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()

v6:
* Add synthetic SecureTSC x86 feature bit
* Drop {__enc,dec}_payload() as they are pretty small and has one caller.
* Instead of a pointer use data_npages as variable
* Beautify struct snp_guest_req
* Make vmpck_id as unsigned int in snp_assign_vmpck()
* Move most of the functions to end of sev.c file
* Update commit/comments/error messages
* Mark free_shared_pages and alloc_shared_pages as inline
* Free snp_dev->certs_data when guest driver is removed
* Add lockdep assert in snp_inc_msg_seqno()
* Drop redundant enc_init NULL check
* Move SNP_TSC_INFO_REQ_SZ define out of structure
* Rename guest_tsc_{scale,offset} to snp_tsc_{scale,offset}
* Add new linux termination error code GHCB_TERM_SECURE_TSC
* Initialize and use cmd_mutex in snp_get_tsc_info()
* Set TSC as reliable in sme_early_init()
* Do not print firmware bug for Secure TSC enabled guests

https://lore.kernel.org/lkml/20231128125959.1810039-1-nikunj@amd.com/

v5:
* Rebased on v6.6 kernel
* Dropped link tag in first patch
* Dropped get_ctx_authsize() as it was redundant

https://lore.kernel.org/lkml/20231030063652.68675-1-nikunj@amd.com/

v4:
* Drop handle_guest_request() and handle_guest_request_ext()
* Drop NULL check for key
* Corrected commit subject
* Added Reviewed-by from Tom

https://lore.kernel.org/lkml/20230814055222.1056404-1-nikunj@amd.com/

v3:
* Updated commit messages
* Made snp_setup_psp_messaging() generic that is accessed by both the
  kernel and the driver
* Moved most of the context information to sev.c, sev-guest driver
  does not need to know the secrets page layout anymore
* Add CC_ATTR_GUEST_SECURE_TSC early in the series therefore it can be
  used in later patches.
* Removed data_gpa and data_npages from struct snp_req_data, as certs_data
  and its size is passed to handle_guest_request_ext()
* Make vmpck_id as unsigned int
* Dropped unnecessary usage of memzero_explicit()
* Cache secrets_pa instead of remapping the cc_blob always
* Rebase on top of v6.4 kernel
https://lore.kernel.org/lkml/20230722111909.15166-1-nikunj@amd.com/

v2:
* Rebased on top of v6.3-rc3 that has Boris's sev-guest cleanup series
  https://lore.kernel.org/r/20230307192449.24732-1-bp@alien8.de/

v1: https://lore.kernel.org/r/20230130120327.977460-1-nikunj@amd.com/

Nikunj A Dadhania (16):
  virt: sev-guest: Use AES GCM crypto library
  virt: sev-guest: Replace dev_dbg with pr_debug
  virt: sev-guest: Add SNP guest request structure
  virt: sev-guest: Add vmpck_id to snp_guest_dev struct
  x86/sev: Cache the secrets page address
  virt: sev-guest: Move SNP Guest command mutex
  x86/sev: Move and reorganize sev guest request api
  x86/mm: Add generic guest initialization hook
  x86/cpufeatures: Add synthetic Secure TSC bit
  x86/sev: Add Secure TSC support for SNP guests
  x86/sev: Change TSC MSR behavior for Secure TSC enabled guests
  x86/sev: Prevent RDTSC/RDTSCP interception for Secure TSC enabled
    guests
  x86/kvmclock: Skip kvmclock when Secure TSC is available
  x86/sev: Mark Secure TSC as reliable
  x86/cpu/amd: Do not print FW_BUG for Secure TSC
  x86/sev: Enable Secure TSC for SNP guests

 arch/x86/Kconfig                        |   1 +
 arch/x86/boot/compressed/sev.c          |   3 +-
 arch/x86/include/asm/cpufeatures.h      |   1 +
 arch/x86/include/asm/sev-common.h       |   1 +
 arch/x86/include/asm/sev-guest.h        | 190 +++++++
 arch/x86/include/asm/sev.h              |  21 +-
 arch/x86/include/asm/svm.h              |   6 +-
 arch/x86/include/asm/x86_init.h         |   2 +
 arch/x86/kernel/cpu/amd.c               |   3 +-
 arch/x86/kernel/kvmclock.c              |   2 +-
 arch/x86/kernel/sev-shared.c            |  10 +
 arch/x86/kernel/sev.c                   | 649 +++++++++++++++++++++--
 arch/x86/kernel/x86_init.c              |   2 +
 arch/x86/mm/mem_encrypt.c               |  12 +-
 arch/x86/mm/mem_encrypt_amd.c           |  12 +
 drivers/virt/coco/sev-guest/Kconfig     |   3 -
 drivers/virt/coco/sev-guest/sev-guest.c | 668 +++---------------------
 drivers/virt/coco/sev-guest/sev-guest.h |  63 ---
 18 files changed, 917 insertions(+), 732 deletions(-)
 create mode 100644 arch/x86/include/asm/sev-guest.h
 delete mode 100644 drivers/virt/coco/sev-guest/sev-guest.h


base-commit: ceb6a6f023fd3e8b07761ed900352ef574010bcb
  

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