lkml.org 
[lkml]   [2021]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 5/6] platform/x86: intel_tdx_attest: Add TDX Guest attestation interface driver
On Thu, Jul 8, 2021 at 5:36 PM Andi Kleen <ak@linux.intel.com> wrote:
>
>
> On 7/8/2021 5:20 PM, Dan Williams wrote:
> >
> > If you have a lock would TDX KVM even notice that its parallel
> > requests are being handled serially? I.e. even if they said "yes,
> > multiple requests may happen in parallel", until it becomes an actual
> > latency problem in practice it's not clear that this generous use of
> > resources is justified.
> The worst case usage is 2 pages * file descriptor. There are lots of
> other ways to use that much and more memory for each file descriptor.
>
> >
> > Scratch that... this driver already has the attestation_lock! So, it's
> > already the case that only one thread can be attesting at a time. The
> > per-file buffer is unecessary.
>
> But then you couldn't free the buffer. So it would be leaked forever for
> likely only one attestation.
>
> Not sure what problem you're trying to solve here.

One allocation for the life of the driver that can have its direct map
permissions changed rather than an allocation per-file descriptor and
fragmenting the direct map.

> > keyutils supports generating and passing blobs into and out of the
> > kernel with a handle associated to those blobs. This driver adds a TDX
> > way to pass blobs into and out of the kernel. If Linux grows other
> > TDX-like attestation requirements in the future (e.g. PCI SPDM) should
> > each of those invent their own user ABI for passing blobs around?
>
> The TDX blobs are different than any blobs that keyutils supports today.
> The TDX operations are different too.
>
> TDREPORT doesn't even involve any keys, it's just attestation reports.
>
> keyutils today nothing related to attestation.
>
> I just don't see any commonality. If there was commonality it would be
> more with the TPM interface, but TDX attestation is different enough
> that it also isn't feasible to directly convert it into TPM operation
> (apart from standard TPM being a beast that you better avoid as much as
> possible anyways)
>

Ok. I'll leave that alone for TDX, but I still have my eyes on
keyutils for aspects of PCI SPDM.

\
 
 \ /
  Last update: 2021-07-09 03:38    [W:0.276 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site