[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ebd90e46-d2ac-48ed-8d7e-ffc8a221140f@amd.com>
Date: Sat, 27 Jan 2024 09:40:41 +0530
From: "Nikunj A. Dadhania" <nikunj@....com>
To: Dionna Amalie Glaze <dionnaglaze@...gle.com>
Cc: linux-kernel@...r.kernel.org, thomas.lendacky@....com, x86@...nel.org,
kvm@...r.kernel.org, bp@...en8.de, mingo@...hat.com, tglx@...utronix.de,
dave.hansen@...ux.intel.com, pgonda@...gle.com, seanjc@...gle.com,
pbonzini@...hat.com
Subject: Re: [PATCH v7 00/16] Add Secure TSC support for SNP guests
On 1/26/2024 6:30 AM, Dionna Amalie Glaze wrote:
> On Wed, Jan 24, 2024 at 10:08 PM Nikunj A. Dadhania <nikunj@....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
Powered by blists - more mailing lists