[PATCH v12 00/19] Add Secure TSC support for SNP guests

Nikunj A Dadhania posted 19 patches 1 month, 2 weeks ago
There is a newer version of this series
arch/x86/include/asm/msr-index.h        |   1 +
arch/x86/include/asm/sev-common.h       |   1 +
arch/x86/include/asm/sev.h              | 165 +++++-
arch/x86/include/asm/svm.h              |   6 +-
include/linux/cc_platform.h             |   8 +
arch/x86/boot/compressed/sev.c          |   3 +-
arch/x86/coco/core.c                    |   3 +
arch/x86/coco/sev/core.c                | 612 +++++++++++++++++++--
arch/x86/coco/sev/shared.c              |  10 +
arch/x86/kernel/cpu/amd.c               |   3 +-
arch/x86/kernel/kvmclock.c              |  42 +-
arch/x86/kernel/tsc.c                   |  22 +
arch/x86/mm/mem_encrypt.c               |   4 +
arch/x86/mm/mem_encrypt_amd.c           |   4 +
arch/x86/mm/mem_encrypt_identity.c      |  11 +-
drivers/virt/coco/sev-guest/sev-guest.c | 671 +++---------------------
arch/x86/Kconfig                        |   1 +
drivers/virt/coco/sev-guest/Kconfig     |   3 -
18 files changed, 891 insertions(+), 679 deletions(-)
[PATCH v12 00/19] Add Secure TSC support for SNP guests
Posted by Nikunj A Dadhania 1 month, 2 weeks ago
This patchset is also available at:

  https://github.com/AMDESE/linux-kvm/tree/sectsc-guest-latest

and is based on v6.12-rc2

Overview
--------

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".

In order to enable secure TSC, SEV-SNP guests need to send a TSC_INFO guest
message before the APs are booted. Details from the TSC_INFO response will
then be used to program the VMSA before the APs are brought up. See "SEV
Secure Nested Paging Firmware ABI Specification" document (currently at
https://www.amd.com/system/files/TechDocs/56860.pdf) section "TSC Info"

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 APs are started, move the guest messaging code from
sev-guest driver to sev/core.c and provide well defined APIs to the
sev-guest driver.

Patches:
   01: Use AES GCM library
02-03: SNP init error handling and cache secrets page address
04-06: Preparatory patches for code movement
07-08: Patches moving SNP guest messaging code from SEV guest driver to
       SEV common code
09-14: SecureTSC enablement patches
15-16: Generic TSC/kvmclock improvements
17-19: SecureTSC enablement patches.

Testing SecureTSC
-----------------

SecureTSC hypervisor patches based on top of SEV-SNP Guest MEMFD series:
https://github.com/AMDESE/linux-kvm/tree/sectsc-host-latest

QEMU changes:
https://github.com/nikunjad/qemu/tree/snp-securetsc-latest

QEMU commandline SEV-SNP with SecureTSC:

  qemu-system-x86_64 -cpu EPYC-Milan-v2 -smp 4 \
    -object memory-backend-memfd,id=ram1,size=1G,share=true,prealloc=false,reserve=false \
    -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on \
    -machine q35,confidential-guest-support=sev0,memory-backend=ram1 \
    ...

Changelog:
----------
v12:
* Rebased on top of v6.12-rc2
* Collected Reviewed-by (Tom)
* Improve error handling in sme_enable() (Boris)
* Drop handle_guest_request() copying routine (Boris)
* Move VMPCK empty check inside the lock (Tom)
* Drop export symbol for snp_issue_guest_request() (Tom)
* Rename CC_ATTR_GUEST_SECURE_TSC as CC_ATTR_GUEST_SNP_SECURE_TSC (Tom)
* Upgrade the tsc early and regular clock rating when TSC is invariant,
  non-stop and stable (tglx)
* Initialize kvm sched clock only when the kvmclock source is selected (Sean)
* Abort SecureTSC enabled guests when kvmclock is selected (Sean)
* Added patch to use TSC frequency using GUEST_TSC_FREQ MSR (Sean)

v11: https://lore.kernel.org/lkml/20240731150811.156771-1-nikunj@amd.com/
* Rebased on top of v6.11-rc1
* Added Acked-by/Reviewed-by
* Moved SEV Guest driver cleanups in the beginning of the series
* Commit message updates
* Enforced PAGE_SIZE constraints for snp_guest_msg
* After offline discussion with Boris, redesigned and exported
  SEV guest messaging APIs to sev-guest driver
* Dropped VMPCK rework patches
* Make sure movement of SEV core routines does not break the SEV Guest
  driver midway of the series.


Nikunj A Dadhania (19):
  virt: sev-guest: Use AES GCM crypto library
  x86/sev: Handle failures from snp_init()
  x86/sev: Cache the secrets page address
  virt: sev-guest: Consolidate SNP guest messaging parameters to a
    struct
  virt: sev-guest: Reduce the scope of SNP command mutex
  virt: sev-guest: Carve out SNP message context structure
  x86/sev: Carve out and export SNP guest messaging init routines
  x86/sev: Relocate SNP guest messaging routines to common code
  x86/cc: Add CC_ATTR_GUEST_SNP_SECURE_TSC
  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/sev: Mark Secure TSC as reliable clocksource
  tsc: Use the GUEST_TSC_FREQ MSR for discovering TSC frequency
  tsc: Upgrade TSC clocksource rating
  x86/kvmclock: Use clock source callback to update kvm sched clock
  x86/kvmclock: Abort SecureTSC enabled guest when kvmclock is selected
  x86/cpu/amd: Do not print FW_BUG for Secure TSC
  x86/sev: Allow Secure TSC feature for SNP guests

 arch/x86/include/asm/msr-index.h        |   1 +
 arch/x86/include/asm/sev-common.h       |   1 +
 arch/x86/include/asm/sev.h              | 165 +++++-
 arch/x86/include/asm/svm.h              |   6 +-
 include/linux/cc_platform.h             |   8 +
 arch/x86/boot/compressed/sev.c          |   3 +-
 arch/x86/coco/core.c                    |   3 +
 arch/x86/coco/sev/core.c                | 612 +++++++++++++++++++--
 arch/x86/coco/sev/shared.c              |  10 +
 arch/x86/kernel/cpu/amd.c               |   3 +-
 arch/x86/kernel/kvmclock.c              |  42 +-
 arch/x86/kernel/tsc.c                   |  22 +
 arch/x86/mm/mem_encrypt.c               |   4 +
 arch/x86/mm/mem_encrypt_amd.c           |   4 +
 arch/x86/mm/mem_encrypt_identity.c      |  11 +-
 drivers/virt/coco/sev-guest/sev-guest.c | 671 +++---------------------
 arch/x86/Kconfig                        |   1 +
 drivers/virt/coco/sev-guest/Kconfig     |   3 -
 18 files changed, 891 insertions(+), 679 deletions(-)


base-commit: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b
-- 
2.34.1
Re: [PATCH v12 00/19] Add Secure TSC support for SNP guests
Posted by Dave Hansen 1 month, 2 weeks ago
On 10/9/24 02:28, 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".
> 
> In order to enable secure TSC, SEV-SNP guests need to send a TSC_INFO guest
> message before the APs are booted.

Superficially, this seems kinda silly.  If you ask someone, do you want
more security or less, they usually say "more".

Why do guests need to turn this on instead of just always having a
secure TSC?  There must be _some_ compromise, either backward
compatibility or performance or...
Re: [PATCH v12 00/19] Add Secure TSC support for SNP guests
Posted by Nikunj A. Dadhania 1 month, 2 weeks ago

On 10/9/2024 9:38 PM, Dave Hansen wrote:
> On 10/9/24 02:28, 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".
>>
>> In order to enable secure TSC, SEV-SNP guests need to send a TSC_INFO guest
>> message before the APs are booted.
> 
> Superficially, this seems kinda silly.  If you ask someone, do you want
> more security or less, they usually say "more".

All SNP features are opt-in by default. The option is left to the VMM.
It is similar to having a legacy vs secure VM, the option is left to
the user.
 
> Why do guests need to turn this on instead of just always having a
> secure TSC?  There must be _some_ compromise, either backward
> compatibility or performance or...

Secure TSC has been there since the introduction of Milan when SEV-SNP was
introduced. It wasnt enabled in the kernel yet.

Regards
Nikunj