On Thu, Jul 8, 2021 at 5:36 PM Andi Kleen [off-list ref] wrote:

On 7/8/2021 5:20 PM, Dan Williams wrote:

quoted

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.

quoted

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.

quoted

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.