From: Tom Lendacky <thomas.lendacky@amd.com>
To: Stefano Garzarella <sgarzare@redhat.com>, Borislav Petkov <bp@alien8.de>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Claudio Carvalho <cclaudio@linux.ibm.com>,
Peter Huewe <peterhuewe@gmx.de>,
x86@kernel.org, Dov Murik <dovmurik@linux.ibm.com>,
linux-coco@lists.linux.dev, Dionna Glaze <dionnaglaze@google.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC PATCH v2 2/6] x86/sev: add SVSM vTPM probe/send_command functions
Date: Mon, 10 Mar 2025 08:27:37 -0500 [thread overview]
Message-ID: <3dd645f2-476a-d0d5-c8c1-c87307f2d756@amd.com> (raw)
In-Reply-To: <mjftygohmhgs6daqvgkh2jbfuqjquchcaovcjtnzyhilnt5ww5@l3fr7phqh2ps>
On 3/10/25 07:46, Stefano Garzarella wrote:
> On Mon, Mar 10, 2025 at 12:30:06PM +0100, Borislav Petkov wrote:
>> On Fri, Feb 28, 2025 at 06:07:16PM +0100, Stefano Garzarella wrote:
>>> +bool snp_svsm_vtpm_probe(void)
>>> +{
>>> + struct svsm_call call = {};
>>> + u64 send_cmd_mask = 0;
>>> + u64 platform_cmds;
>>> + u64 features;
>>> + int ret;
>>> +
>>> + /* The vTPM device is available only if we have a SVSM */
>>
>> s/if we have a SVSM/if an SVSM is present/
>>
>>> + if (!snp_vmpl)
>>> + return false;
>>> +
>>> + call.caa = svsm_get_caa();
>>> + call.rax = SVSM_VTPM_CALL(SVSM_VTPM_QUERY);
>>> +
>>> + ret = svsm_perform_call_protocol(&call);
>>> +
>>
>>
>> ^ Superfluous newline.
>>
>>> + if (ret != SVSM_SUCCESS)
>>> + return false;
>>> +
>>> + features = call.rdx_out;
>>> + platform_cmds = call.rcx_out;
>>> +
>>> + /* No feature supported, it should be zero */
>>> + if (features)
>>> + pr_warn("SNP SVSM vTPM unsupported features: 0x%llx\n",
>>> + features);
>>
>> So
>>
>> return false;
>>
>> here?
>
> In v1 we had that, but Tom Lendacky suggested to remove it:
> https://lore.kernel.org/linux-integrity/4valfkw7wtx3fpdv2qbymzggcu7mp4mhkd65j5q7zncs2dzorc@jjjevuwfchgl/
>
> IIUC the features are supposed to be additive, so Tom's point was to
> avoid that in the future SVSM will supports new features and this driver
> stops working, when it could, just without using the new features.
>
> I added a warning just to be aware of new features, but I can remove it.
I don't think anything needs to be checked or printed. If you want to do
anything, just issue a pr_info() with the features value (and maybe the
platform_cmds value, too). Issuing a pr_warn() here would be like
issuing a pr_warn() for a new CPUID value that the current kernel
doesn't know about.
Thanks,
Tom
>
>>
>>> +
>>> + /* TPM_SEND_COMMAND - platform command 8 */
>>> + send_cmd_mask = 1 << 8;
>>
>> BIT_ULL(8);
>>
>>> +
>>> + return (platform_cmds & send_cmd_mask) == send_cmd_mask;
>>> +}
>>> +EXPORT_SYMBOL_GPL(snp_svsm_vtpm_probe);
>>> +
>>> +int snp_svsm_vtpm_send_command(u8 *buffer)
>>> +{
>>> + struct svsm_call call = {};
>>> +
>>> + call.caa = svsm_get_caa();
>>> + call.rax = SVSM_VTPM_CALL(SVSM_VTPM_CMD);
>>> + call.rcx = __pa(buffer);
>>> +
>>> + return svsm_perform_call_protocol(&call);
>>> +}
>>
>> In any case, you can zap all those local vars, use comments instead
>> and slim
>> down the function, diff ontop:
>
> Thanks for the diff, I'll apply it except, for now, the return in the
> feature check which is still not clear to me (I think I get Tom's point,
> but I would like confirmation from both of you).
>
> Thanks,
> Stefano
>
>>
>> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
>> index 3902af4b1385..6d7e97c1f567 100644
>> --- a/arch/x86/coco/sev/core.c
>> +++ b/arch/x86/coco/sev/core.c
>> @@ -2631,12 +2631,9 @@ static int snp_issue_guest_request(struct
>> snp_guest_req *req, struct snp_req_dat
>> bool snp_svsm_vtpm_probe(void)
>> {
>> struct svsm_call call = {};
>> - u64 send_cmd_mask = 0;
>> - u64 platform_cmds;
>> - u64 features;
>> int ret;
>>
>> - /* The vTPM device is available only if we have a SVSM */
>> + /* The vTPM device is available only if a SVSM is present */
>> if (!snp_vmpl)
>> return false;
>>
>> @@ -2644,22 +2641,17 @@ bool snp_svsm_vtpm_probe(void)
>> call.rax = SVSM_VTPM_CALL(SVSM_VTPM_QUERY);
>>
>> ret = svsm_perform_call_protocol(&call);
>> -
>> if (ret != SVSM_SUCCESS)
>> return false;
>>
>> - features = call.rdx_out;
>> - platform_cmds = call.rcx_out;
>> -
>> /* No feature supported, it should be zero */
>> - if (features)
>> - pr_warn("SNP SVSM vTPM unsupported features: 0x%llx\n",
>> - features);
>> -
>> - /* TPM_SEND_COMMAND - platform command 8 */
>> - send_cmd_mask = 1 << 8;
>> + if (call.rdx_out) {
>> + pr_warn("SNP SVSM vTPM unsupported features: 0x%llx\n",
>> call.rdx_out);
>> + return false;
>> + }
>>
>> - return (platform_cmds & send_cmd_mask) == send_cmd_mask;
>> + /* Check platform commands is TPM_SEND_COMMAND - platform command
>> 8 */
>> + return (call.rcx_out & BIT_ULL(8)) == BIT_ULL(8);
>> }
>> EXPORT_SYMBOL_GPL(snp_svsm_vtpm_probe);
>>
>>
>> --
>> Regards/Gruss,
>> Boris.
>>
>> https://people.kernel.org/tglx/notes-about-netiquette
>>
>
next prev parent reply other threads:[~2025-03-10 13:27 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-28 17:07 [RFC PATCH v2 0/6] Enlightened vTPM support for SVSM on SEV-SNP Stefano Garzarella
2025-02-28 17:07 ` [RFC PATCH v2 1/6] x86/sev: add SVSM call macros for the vTPM protocol Stefano Garzarella
2025-03-10 11:08 ` Borislav Petkov
2025-03-10 12:13 ` Stefano Garzarella
2025-02-28 17:07 ` [RFC PATCH v2 2/6] x86/sev: add SVSM vTPM probe/send_command functions Stefano Garzarella
2025-03-10 11:30 ` Borislav Petkov
2025-03-10 12:46 ` Stefano Garzarella
2025-03-10 13:27 ` Tom Lendacky [this message]
2025-03-10 13:51 ` Borislav Petkov
2025-03-10 13:56 ` Tom Lendacky
2025-03-10 14:02 ` Borislav Petkov
2025-03-10 13:59 ` Stefano Garzarella
2025-03-10 14:04 ` Borislav Petkov
2025-02-28 17:07 ` [RFC PATCH v2 3/6] tpm: add send_recv() ops in tpm_class_ops Stefano Garzarella
2025-03-01 1:45 ` Jarkko Sakkinen
2025-03-03 16:21 ` Stefano Garzarella
2025-03-04 16:56 ` Jarkko Sakkinen
2025-03-04 20:21 ` Jarkko Sakkinen
2025-03-05 9:04 ` Stefano Garzarella
2025-03-05 19:02 ` Jason Gunthorpe
2025-03-06 21:52 ` Jarkko Sakkinen
2025-03-07 15:37 ` Stefano Garzarella
2025-03-07 16:32 ` Jarkko Sakkinen
2025-03-06 22:15 ` Jarkko Sakkinen
2025-03-07 15:37 ` Stefano Garzarella
2025-03-03 14:06 ` Tom Lendacky
2025-03-03 17:29 ` Stefano Garzarella
2025-02-28 17:07 ` [RFC PATCH v2 4/6] tpm: add interface to interact with devices based on TCG Simulator Stefano Garzarella
2025-03-01 1:48 ` Jarkko Sakkinen
2025-03-03 16:41 ` Stefano Garzarella
2025-03-04 15:23 ` Stefano Garzarella
2025-03-04 17:14 ` Jarkko Sakkinen
2025-03-03 14:28 ` Tom Lendacky
2025-03-03 17:30 ` Stefano Garzarella
2025-02-28 17:07 ` [RFC PATCH v2 5/6] tpm: add SNP SVSM vTPM driver Stefano Garzarella
2025-03-01 0:28 ` Jason Gunthorpe
2025-03-03 16:19 ` Stefano Garzarella
2025-03-03 18:24 ` Jason Gunthorpe
2025-03-01 1:51 ` Jarkko Sakkinen
2025-03-01 3:57 ` Dionna Amalie Glaze
2025-03-03 16:46 ` Stefano Garzarella
2025-03-04 17:27 ` Jarkko Sakkinen
2025-03-05 9:07 ` Stefano Garzarella
2025-02-28 17:07 ` [RFC PATCH v2 6/6] x86/sev: register tpm-svsm platform device Stefano Garzarella
2025-03-01 0:30 ` [RFC PATCH v2 0/6] Enlightened vTPM support for SVSM on SEV-SNP Jason Gunthorpe
2025-03-03 16:20 ` Stefano Garzarella
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=3dd645f2-476a-d0d5-c8c1-c87307f2d756@amd.com \
--to=thomas.lendacky@amd.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bp@alien8.de \
--cc=cclaudio@linux.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=dovmurik@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jroedel@suse.de \
--cc=linux-coco@lists.linux.dev \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterhuewe@gmx.de \
--cc=sgarzare@redhat.com \
--cc=tglx@linutronix.de \
--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