From: "Nikunj A. Dadhania" <nikunj@amd.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Cc: bp@alien8.de, dionnaglaze@google.com, pgonda@google.com,
seanjc@google.com, pbonzini@redhat.com, michael.roth@amd.com,
ketanch@iitk.ac.in
Subject: Re: [PATCH v2 08/11] x86/sev: Add Secure TSC support for SNP guests
Date: Wed, 5 Apr 2023 13:07:28 +0530 [thread overview]
Message-ID: <d6b6a322-700b-8507-c52e-30ac143f6df1@amd.com> (raw)
In-Reply-To: <027ac704-2a7b-9ac7-d2c9-584ed840666e@amd.com>
On 4/4/2023 3:11 AM, Tom Lendacky wrote:
> On 3/26/23 09:46, Nikunj A Dadhania wrote:
>> Add support for Secure TSC in SNP enabled guests. Secure TSC
>> allows guest to securely use RDTSC/RDTSCP instructions as the
>> parameters being used cannot be changed by hypervisor once the
>> guest is launched.
>>
>> During the boot-up of the secondary cpus, SecureTSC enabled
>> guests need to query TSC info from Security processor (PSP).
>
> s/Security processor (PSP)/AMD Secure Processor/
>
>> This communication channel is encrypted between the security
>
> here as well.
>
>> processor and the guest, hypervisor is just the conduit to
>
> s/hypervisor/the hypervisor/
>
Sure, will change commit message
>> deliver the guest messages to the security processor. Each
>> message is protected with an AEAD (AES-256 GCM). Use minimal
>> GCM library to encrypt/decrypt SNP Guest messages to communicate
>> with the PSP.
>>
>> Moreover, the hypervisor should not be intercepting RDTSC/RDTSCP
>> when Secure TSC is enabled. A #VC exception will be generated if
>> the RDTSC/RDTSCP instructions are being intercepted. If this should
>> occur and Secure TSC is enabled, terminate guest execution.
>
> This seems like a separate patch.
Sure.
>>
>> Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
>> ---
>> diff --git a/arch/x86/include/asm/sev-guest.h b/arch/x86/include/asm/sev-guest.h
>> index 834cdae302ad..d5ed041ce06b 100644
>> --- a/arch/x86/include/asm/sev-guest.h
>> +++ b/arch/x86/include/asm/sev-guest.h
>> +#define SNP_TSC_INFO_REQ_SZ 128
>> + /* Must be zero filled */
>> + u8 rsvd[SNP_TSC_INFO_REQ_SZ];
>> +} __packed;
>> +
>> +struct snp_tsc_info_resp {
>> + /* Status of TSC_INFO message */
>> + u32 status;
>> + u32 rsvd1;
>> + u64 tsc_scale;
>> + u64 tsc_offset;
>> + u64 tsc_factor;
>
> This should be a u32 ...
>
Right, will correct.
>> + u8 rsvd2[96];
>
> Which then makes this 100.
Yes.
>> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c
>> index 3750e545d688..280aaa1e6aad 100644
>> --- a/arch/x86/kernel/sev.c
>> +++ b/arch/x86/kernel/sev.c
>> +bool __init snp_secure_tsc_prepare(void)
>> +{
>> + platform_data = kzalloc(sizeof(*platform_data), GFP_KERNEL);
>> + if (!platform_data)
>> + return false;
>> +
>> + /* Initialize the PSP channel to send snp messages */
>> + if (snp_setup_psp_messaging(platform_data))
>> + sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
>> +
>> + if (cc_platform_has(CC_ATTR_GUEST_SECURE_TSC)) {
>
> Should this be checked before allocating memory and calling snp_setup_psp_messaging()?
No, as we need guest messaging to work without Secure TSC as well.
> Also, I notice here you use the cc_platform_has() function but in previous
> patches you check sev_status directly.
For sev-shared.c, cc_platform_has() is not available when compiling boot/compressed.
I will change the below call site to cc_platfrom_has() after testing.
arch/x86/kernel/sev.c: if (regs->cx == MSR_IA32_TSC && (sev_status & MSR_AMD64_SNP_SECURE_TSC)) {
> And you don't implement support for
> CC_ATTR_GUEST_SECURE_TSC until the last patch instead of now.
This is to make sure that SECURE_TSC is enabled only after the last patch.
As cc_platform_has() is being used at multiple places to enable the feature.
> You can't get here until SNP_FEATURES_PRESENT is updated.
>
>> + if (snp_get_tsc_info())
>> + sev_es_terminate(SEV_TERM_SET_GEN, GHCB_SNP_UNSUPPORTED);
>> +
>> + pr_info("SecureTSC enabled\n");
>> + }
>
> Blank line.
Sure
Regards
Nikunj
next prev parent reply other threads:[~2023-04-05 7:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-26 14:46 [PATCH v2 00/11] " Nikunj A Dadhania
2023-03-26 14:46 ` [PATCH v2 01/11] virt: sev-guest: Use AES GCM crypto library Nikunj A Dadhania
2023-04-03 19:09 ` Tom Lendacky
2023-04-05 5:10 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 02/11] virt: sev-guest: Move mutex to SNP guest device structure Nikunj A Dadhania
2023-04-03 19:13 ` Tom Lendacky
2023-04-05 5:23 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 03/11] virt: sev-guest: Add snp_guest_req structure Nikunj A Dadhania
2023-04-03 19:59 ` Tom Lendacky
2023-04-05 5:31 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 04/11] virt: sev-guest: Add simplified helper to assign vmpck Nikunj A Dadhania
2023-04-03 20:26 ` Tom Lendacky
2023-04-05 6:18 ` Nikunj A. Dadhania
2023-04-10 16:31 ` Peter Gonda
2023-04-14 4:51 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 05/11] x86/sev: Move and reorganize sev guest request api Nikunj A Dadhania
2023-04-03 21:01 ` Tom Lendacky
2023-04-05 7:11 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 06/11] x86/mm: Add generic guest initialization hook Nikunj A Dadhania
2023-03-26 14:46 ` [PATCH v2 07/11] x86/sev: Change TSC MSR behavior for Secure TSC enabled guests Nikunj A Dadhania
2023-04-03 21:15 ` Tom Lendacky
2023-03-26 14:46 ` [PATCH v2 08/11] x86/sev: Add Secure TSC support for SNP guests Nikunj A Dadhania
2023-04-03 21:41 ` Tom Lendacky
2023-04-05 7:37 ` Nikunj A. Dadhania [this message]
2023-04-05 13:24 ` Tom Lendacky
2023-04-05 14:37 ` Nikunj A. Dadhania
2023-04-10 17:14 ` Peter Gonda
2023-04-14 5:10 ` Nikunj A. Dadhania
2023-03-26 14:46 ` [PATCH v2 09/11] x86/kvmclock: Use Secure TSC as clock if available Nikunj A Dadhania
2023-04-03 21:45 ` Tom Lendacky
2023-04-05 8:16 ` Nikunj A. Dadhania
2023-03-26 14:47 ` [PATCH v2 10/11] x86/tsc: Mark Secure TSC as reliable clocksource Nikunj A Dadhania
2023-03-26 14:47 ` [PATCH v2 11/11] x86/sev: Enable Secure TSC for SNP guests Nikunj A Dadhania
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d6b6a322-700b-8507-c52e-30ac143f6df1@amd.com \
--to=nikunj@amd.com \
--cc=bp@alien8.de \
--cc=dionnaglaze@google.com \
--cc=ketanch@iitk.ac.in \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®