From: Dan Williams <dan.j.williams@intel.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
<linux-coco@lists.linux.dev>, <svsm-devel@coconut-svsm.dev>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
Dan Williams <dan.j.williams@intel.com>,
Michael Roth <michael.roth@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Joel Becker <jlbec@evilplan.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM
Date: Mon, 15 Apr 2024 23:09:33 -0700 [thread overview]
Message-ID: <661e161db9034_4d56129418@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <eb745e16-b3eb-0e9c-59c8-45aa01244386@amd.com>
Tom Lendacky wrote:
> On 4/15/24 16:50, Kuppuswamy Sathyanarayanan wrote:
> >
> > On 4/15/24 1:13 PM, Tom Lendacky wrote:
> >> On 4/15/24 14:48, Kuppuswamy Sathyanarayanan wrote:
> >>> Hi,
> >>>
> >>> On 4/15/24 12:16 PM, Tom Lendacky wrote:
> >>>> On 4/12/24 10:52, Tom Lendacky wrote:
> >>>>> On 4/9/24 13:12, Kuppuswamy Sathyanarayanan wrote:
> >>>>>> On 3/25/24 3:26 PM, Tom Lendacky wrote:
> >>>>>>> Config-fs provides support to hide individual attribute entries. Using
> >>>>>>> this support, base the display of the SVSM related entries on the presence
> >>>>>>> of an SVSM.
> >>>>>>>
> >>>>>>> Cc: Joel Becker <jlbec@evilplan.org>
> >>>>>>> Cc: Christoph Hellwig <hch@lst.de>
> >>>>>>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >>>>>>> ---
> >>>>>>> arch/x86/coco/core.c | 4 ++++
> >>>>>>> drivers/virt/coco/tsm.c | 14 ++++++++++----
> >>>>>>> include/linux/cc_platform.h | 8 ++++++++
> >>>>>>> 3 files changed, 22 insertions(+), 4 deletions(-)
> >>>>>>>
> >>>>
> >>>>>>
> >>>>>> Any comment about the following query? I think introducing a CC flag for this use
> >>>>>> case is over kill.
> >>>>>>
> >>>>>> https://lore.kernel.org/lkml/6b90b223-46e0-4e6d-a17c-5caf72e3c949@linux.intel.com/
> >>>>>
> >>>>> If you don't think TDX will be able to make use of the SVSM attribute I can look at adding a callback. But I was waiting to see if anyone else had comments, for or against, before re-doing it all.
> >>>>>
> >>>>
> >>>> What about something like this (applied on top of patch 13):
> >>>>
> >>
> >>>> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> >>>> index 27cc97fe8dcd..5aaf626d178d 100644
> >>>> --- a/include/linux/tsm.h
> >>>> +++ b/include/linux/tsm.h
> >>>> @@ -74,7 +74,20 @@ extern const struct config_item_type tsm_report_default_type;
> >>>> /* publish @privlevel, @privlevel_floor, and @auxblob attributes */
> >>>> extern const struct config_item_type tsm_report_extra_type;
> >>>> +/*
> >>>> + * Used to indicate the attribute group type to the visibility callback to
> >>>> + * avoid the callback having to examine the attribute name.
> >>>
> >>> Checking the attribute name will give more flexibility, right? Since it is one time
> >>> check, it should not be costly, right?
> >>
> >> I thought about checking the name(s), but what if in the future another attribute is added, then you have to remember to update multiple places. This way you have an enum that represents the related attributes. Is there a
> >
> > I think it depends on how you implement the visibility function. If the vendor driver allows all attributes by default and denies few selected ones, you don't have to update the vendor driver for all new attributes. Letting the vendor driver decide whether to support any new attributes makes sense to me.
> >
> >> scenario where you would want to not hide all attributes that are related? String comparisons just seem awkward to me.
> >>
> >> I suppose the config_item and configfs_attr could also be supplied on the callback if that's a requirement.
> >
> >
> > I am ok with enum based checks. But lets see what others think. Personally I think checking config attr name is more flexible.
>
> I think we can do both. Supply the enum, config_item and configfs_attr
> and then the callback can decide using the enum and/or the attribute name.
>
> It could be extended to the current extra attributes, too. The enum
> could have a TSM_TYPE_EXTRA (for the privlevel, privlevel_floor and
> auxblob) and allow those to be hidden as appropriate, too.
>
I guess I should have read all feedback before supplying my own, but
looks like you arrived at the same result.
next prev parent reply other threads:[~2024-04-16 6:09 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 22:26 [PATCH v3 00/14] Provide SEV-SNP support for running under an SVSM Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 01/14] x86/sev: Rename snp_init() in the boot/compressed/sev.c file Tom Lendacky
2024-04-09 17:09 ` Borislav Petkov
2024-04-09 17:44 ` Tom Lendacky
2024-04-09 17:57 ` Borislav Petkov
2024-04-12 16:19 ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 02/14] x86/sev: Make the VMPL0 checking function more generic Tom Lendacky
2024-04-12 16:41 ` Gupta, Pankaj
2024-04-17 11:46 ` Borislav Petkov
2024-04-17 20:35 ` Tom Lendacky
2024-04-17 20:50 ` Borislav Petkov
2024-04-18 18:38 ` Tom Lendacky
2024-04-21 7:12 ` Borislav Petkov
2024-03-25 22:26 ` [PATCH v3 03/14] x86/sev: Check for the presence of an SVSM in the SNP Secrets page Tom Lendacky
2024-04-12 17:03 ` Gupta, Pankaj
2024-04-17 20:40 ` Borislav Petkov
2024-04-18 21:17 ` Tom Lendacky
2024-04-22 22:07 ` Borislav Petkov
2024-03-25 22:26 ` [PATCH v3 04/14] x86/sev: Use kernel provided SVSM Calling Areas Tom Lendacky
2024-04-12 16:04 ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 05/14] x86/sev: Perform PVALIDATE using the SVSM when not at VMPL0 Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 06/14] x86/sev: Use the SVSM to create a vCPU when not in VMPL0 Tom Lendacky
2024-04-12 15:28 ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 07/14] x86/sev: Provide SVSM discovery support Tom Lendacky
2024-04-15 16:12 ` Gupta, Pankaj
2024-03-25 22:26 ` [PATCH v3 08/14] x86/sev: Provide guest VMPL level to userspace Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 09/14] virt: sev-guest: Choose the VMPCK key based on executing VMPL Tom Lendacky
2024-04-16 4:54 ` Dan Williams
2024-04-16 15:17 ` Tom Lendacky
2024-04-16 15:47 ` Dan Williams
2024-03-25 22:26 ` [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor attribute to be updated Tom Lendacky
2024-04-16 4:55 ` Dan Williams
2024-04-16 15:23 ` Tom Lendacky
2024-04-16 15:57 ` Dan Williams
2024-04-16 16:17 ` Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 11/14] x86/sev: Extend the config-fs attestation support for an SVSM Tom Lendacky
2024-04-16 5:37 ` Dan Williams
2024-04-16 15:53 ` Tom Lendacky
2024-04-16 16:19 ` Dan Williams
2024-03-25 22:26 ` [PATCH v3 12/14] fs/configfs: Add a callback to determine attribute visibility Tom Lendacky
2024-04-16 5:46 ` Dan Williams
2024-04-16 16:01 ` Tom Lendacky
2024-04-16 18:25 ` Dan Williams
2024-04-16 19:54 ` Tom Lendacky
2024-04-16 20:03 ` Dan Williams
2024-03-25 22:26 ` [PATCH v3 13/14] x86/sev: Hide SVSM attestation entries if not running under an SVSM Tom Lendacky
2024-04-09 18:12 ` Kuppuswamy Sathyanarayanan
2024-04-12 15:52 ` Tom Lendacky
2024-04-15 19:16 ` Tom Lendacky
2024-04-15 19:48 ` Kuppuswamy Sathyanarayanan
2024-04-15 20:13 ` Tom Lendacky
2024-04-15 21:50 ` Kuppuswamy Sathyanarayanan
2024-04-15 22:03 ` Tom Lendacky
2024-04-16 6:09 ` Dan Williams [this message]
2024-04-16 6:08 ` Dan Williams
2024-04-16 6:05 ` Dan Williams
2024-04-16 5:47 ` Dan Williams
2024-04-16 16:07 ` Tom Lendacky
2024-04-16 6:03 ` Dan Williams
2024-04-16 16:10 ` Tom Lendacky
2024-03-25 22:26 ` [PATCH v3 14/14] x86/sev: Allow non-VMPL0 execution when an SVSM is present Tom Lendacky
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=661e161db9034_4d56129418@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=jlbec@evilplan.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=svsm-devel@coconut-svsm.dev \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.