From: Dan Williams <dan.j.williams@intel.com>
To: Dionna Amalie Glaze <dionnaglaze@google.com>,
Dan Williams <dan.j.williams@intel.com>
Cc: <linux-coco@lists.linux.dev>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Peter Gonda <pgonda@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Samuel Ortiz <sameo@rivosinc.com>,
Thomas Gleixner <tglx@linutronix.de>, <peterz@infradead.org>,
<dave.hansen@linux.intel.com>, <bp@alien8.de>
Subject: Re: [PATCH v6 3/7] configfs-tsm: Introduce a shared ABI for attestation reports
Date: Thu, 12 Oct 2023 22:15:11 -0700 [thread overview]
Message-ID: <6528d25ef1bc3_bfe229442@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <CAAH4kHYKOJcVdbEgey82aRcoaKzRi7qhHAtwG5pVNLWTwV0MGg@mail.gmail.com>
Dionna Amalie Glaze wrote:
> > +What: /sys/kernel/config/tsm/report/$name/privlevel
> > +Date: September, 2023
> > +KernelVersion: v6.7
> > +Contact: linux-coco@lists.linux.dev
> > +Description:
> > + (WO) Attribute is visible if a TSM implementation provider
> > + supports the concept of attestation reports for TVMs running at
> > + different privilege levels, like SEV-SNP "VMPL", specify the
> > + privilege level via this attribute. The minimum acceptable
> > + value is conveyed via @privlevel_floor and the maximum
> > + acceptable value is TSM_PRIVLEVEL_MAX (3).
> > +
>
> I'm unaware of another CC technology that has different privilege
> levels at which to request an attestation, but I'd be much happier to
> see another example here.
I am also unaware of such a CC definition, but the concept seems
generally powerful that I feel (speaking only for myself) it may see
adoption. If that happens it would need to be compatible with this ABI
definition. In the meantime this @privlevel attribute only shows up
when @provider is "sev-guest" to not clutter other implementations.
However, if another CC platform never adopts this concept then this will
be another casualty of the early stage vendor divergence of these
interfaces. The fact that these files are called "blob" and the
Documentation points to per @provider specifications is also evidence of
that. I hope over time the @*blob files become deprecated in favor of
common files with standard formats, but that too remains to be seen.
> I take it my feedback about VLEK vs VCEK selection is going to be left
> for a future patch series? I can drop it if we can agree another WO
> attribute for that won't be met with a lot of barriers, but I think we
> may be generalizing a single data point with the privlevel and key
> selection attributes.
Apologies, I should have addressed key selection in the cover letter. In
general, yes, I think it can be handled with a follow-on patchset, and
from your description it is not clear to me that this needs to be
promoted to configfs-tsm ABI. When you say:
> This is more of a customer-wide policy or machine pool policy.
It makes me think it is amenable to be solved via other means that do
not immediately implicate configfs-tsm ABI. For example KEY_SEL==0 is
defined as:
"If VLEK is installed, sign with VLEK. Otherwise, sign with VCEK."
...so theoretically the machine pool policy could be determined by which
certificate is installed. The customer-wide policy could perhaps be a
sev-guest driver compile-time decision, it need not be something that
each invocation of report generation interface needs to be worried
about.
As for:
> ...if we can agree another WO attribute for that won't be met with a
> lot of barriers
I think peak-level barrier was when I suggested that tdx-guest not
follow the precedent of new per-vendor ioctl() ABI. If we can overcome
that then the relative angst for a KEY_SEL discussion is low.
next prev parent reply other threads:[~2023-10-13 5:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 2:13 [PATCH v6 0/7] configfs-tsm: Attestation Report ABI Dan Williams
2023-10-13 2:14 ` [PATCH v6 1/7] virt: sevguest: Fix passing a stack buffer as a scatterlist target Dan Williams
2023-10-13 2:14 ` [PATCH v6 2/7] virt: coco: Add a coco/Makefile and coco/Kconfig Dan Williams
2023-10-13 2:14 ` [PATCH v6 3/7] configfs-tsm: Introduce a shared ABI for attestation reports Dan Williams
2023-10-13 4:43 ` Dionna Amalie Glaze
2023-10-13 5:15 ` Dan Williams [this message]
2023-10-16 6:36 ` Alexey Kardashevskiy
2023-10-17 2:19 ` Dan Williams
2023-10-17 6:20 ` Alexey Kardashevskiy
2023-10-19 1:29 ` Dan Williams
2023-10-19 20:24 ` Dan Williams
2023-10-13 2:14 ` [PATCH v6 4/7] virt: sevguest: Prep for kernel internal get_ext_report() Dan Williams
2023-10-13 2:14 ` [PATCH v6 5/7] mm/slab: Add __free() support for kvfree Dan Williams
2023-10-13 2:14 ` [PATCH v6 6/7] virt: sevguest: Add TSM_REPORTS support for SNP_GET_EXT_REPORT Dan Williams
2023-10-13 15:38 ` Tom Lendacky
2023-10-14 4:46 ` Dan Williams
2023-10-16 11:36 ` Alexey Kardashevskiy
2023-10-16 15:39 ` Dionna Amalie Glaze
2023-10-16 15:42 ` Peter Gonda
2023-10-17 0:42 ` Alexey Kardashevskiy
2023-10-19 4:30 ` Dan Williams
2023-10-17 4:07 ` Dan Williams
2023-10-17 5:35 ` Alexey Kardashevskiy
2023-10-17 6:28 ` Alexey Kardashevskiy
2023-10-19 4:43 ` Dan Williams
2023-10-19 5:12 ` Alexey Kardashevskiy
2023-10-19 3:34 ` Dan Williams
2023-10-13 2:14 ` [PATCH v6 7/7] virt: tdx-guest: Add Quote generation support using TSM_REPORTS Dan Williams
2023-10-19 18:12 ` Peter Gonda
2023-10-13 15:39 ` [PATCH v6 0/7] configfs-tsm: Attestation Report ABI 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=6528d25ef1bc3_bfe229442@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-coco@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=sameo@rivosinc.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tglx@linutronix.de \
/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.