From: Dan Williams <dan.j.williams@intel.com>
To: Alexey Kardashevskiy <aik@amd.com>, <x86@kernel.org>
Cc: <kvm@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
<linux-pci@vger.kernel.org>, <linux-arch@vger.kernel.org>,
"Sean Christopherson" <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Joerg Roedel <joro@8bytes.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Robin Murphy <robin.murphy@arm.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
Kevin Tian <kevin.tian@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Dan Williams <dan.j.williams@intel.com>,
"Christoph Hellwig" <hch@lst.de>,
Nikunj A Dadhania <nikunj@amd.com>,
Michael Roth <michael.roth@amd.com>,
Vasant Hegde <vasant.hegde@amd.com>,
Joao Martins <joao.m.martins@oracle.com>,
Nicolin Chen <nicolinc@nvidia.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
Steve Sistare <steven.sistare@oracle.com>,
"Lukas Wunner" <lukas@wunner.de>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Dionna Glaze <dionnaglaze@google.com>,
Yi Liu <yi.l.liu@intel.com>, <iommu@lists.linux.dev>,
<linux-coco@lists.linux.dev>, Zhi Wang <zhiw@nvidia.com>,
AXu Yilun <yilun.xu@linux.intel.com>,
"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
Alexey Kardashevskiy <aik@amd.com>
Subject: Re: [RFC PATCH v2 07/22] coco/tsm: Add tsm and tsm-host modules
Date: Thu, 13 Mar 2025 18:14:28 -0700 [thread overview]
Message-ID: <67d382f43dc5d_201f02945a@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20250218111017.491719-8-aik@amd.com>
Alexey Kardashevskiy wrote:
> The TSM module is a library to create sysfs nodes common for hypervisors
> and VMs. It also provides helpers to parse interface reports (required
> by VMs, visible to HVs). It registers 3 device classes:
> - tsm: one per platform,
> - tsm-dev: for physical functions, ("TDEV");
> - tdm-tdi: for PCI functions being assigned to VMs ("TDI").
>
> The library adds a child device of "tsm-dev" or/and "tsm-tdi" class
> for every capable PCI device. Note that the module is made bus-agnostic.
There was some discussion on the merits of "TDEV" and "TDI" objects in
the PCI/TSM thread [1], I will summarize the main objections here:
* PCI device security is a PCI device property. That security property is
not strictly limited to the platform TEE Security Manager (TSM) case.
The PCI device authentication enabling, mentioned as "Lukas's CMA" in
the cover letter, adds a TSM-independent authentication and device
measurement collection ABI. The PCI/TSM proposal simply aims to reuse
that ABI and existing PCI device object lifecycle expectations.
* PCI device security is a PCI specification [2]. The acronym soup of PCI
device security (TDISP, IDE, CMA, SPDM, DOE) is deeply entangled with
PCI specifics. If other buses grow the ability to add devices to a
confidential VM's TCB that future enabling need not be encumbered by
premature adherence to the TDEV+TDI object model, the bus can do what
makes sense for its specific mechanisms. The kernel can abstract common
attributes and ABI without the burden of a new object model.
[1]: http://lore.kernel.org/67b8e5328fd41_2d2c294e5@dwillia2-xfh.jf.intel.com.notmuch
[2]: http://lore.kernel.org/67c128dcb5c21_1a7729454@dwillia2-xfh.jf.intel.com.notmuch
> New device nodes provide sysfs interface for fetching device certificates
> and measurements and TDI interface reports.
> Nodes with the "_user" suffix provide human-readable information, without
> that suffix it is raw binary data to be copied to a guest.
>
> The TSM-HOST module adds hypervisor-only functionality on top. At the
> moment it is:
> - "connect" to enable/disable IDE (a PCI link encryption);
> - "TDI bind" to manage a PCI function passed through to a secure VM.
>
> A platform is expected to register itself in TSM-HOST and provide
> necessary callbacks. No platform is added here, AMD SEV is coming in the
> next patches.
>
> Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
[..]
> diff --git a/drivers/virt/coco/host/tsm-host.c b/drivers/virt/coco/host/tsm-host.c
> new file mode 100644
> index 000000000000..80f3315fb195
> --- /dev/null
> +++ b/drivers/virt/coco/host/tsm-host.c
[..]
> +static ssize_t tsm_dev_status_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + struct tsm_dev *tdev = container_of(dev, struct tsm_dev, dev);
> + struct tsm_dev_status s = { 0 };
> + int ret = tsm_dev_status(tdev, &s);
> + ssize_t ret1;
I know this is just an RFC, but...
> +
> + ret1 = sysfs_emit(buf, "ret=%d\n"
What does "ret" mean to userspace?
> + "ctx_state=%x\n"
This violates the one property per file sysfs expectation.
> + "tc_mask=%x\n"
Is this the Link IDE traffic class?
> + "certs_slot=%x\n"
> + "device_id=%x:%x.%d\n"
> + "segment_id=%x\n"
These last 2 lines are all redundant information relative to the PCI
device name, right?
> + "no_fw_update=%x\n",
> + ret,
> + s.ctx_state,
> + s.tc_mask,
> + s.certs_slot,
> + (s.device_id >> 8) & 0xff,
> + (s.device_id >> 3) & 0x1f,
> + s.device_id & 0x07,
> + s.segment_id,
> + s.no_fw_update);
> +
> + tsm_dev_put(tdev);
I would not expect sysfs to need to manage device references. If the
device is registered sysfs is live and the reference is already
elevated. If the device is unregistered, sysfs is disabled and attribute
handlers are no longer executing.
[..]
> +static ssize_t tsm_tdi_status_user_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct tsm_tdi *tdi = container_of(dev, struct tsm_tdi, dev);
> + struct tsm_dev *tdev = tdi->tdev;
> + struct tsm_host_subsys *hsubsys = (struct tsm_host_subsys *) tdev->tsm;
> + struct tsm_tdi_status ts = { 0 };
> + char algos[256] = "";
> + unsigned int n, m;
> + int ret;
> +
> + ret = tsm_tdi_status(tdi, hsubsys->private_data, &ts);
> + if (ret < 0)
> + return sysfs_emit(buf, "ret=%d\n\n", ret);
> +
> + if (!ts.valid)
> + return sysfs_emit(buf, "ret=%d\nstate=%d:%s\n",
> + ret, ts.state, tdisp_state_to_str(ts.state));
> +
> + n = snprintf(buf, PAGE_SIZE,
> + "ret=%d\n"
> + "state=%d:%s\n"
> + "meas_digest_fresh=%x\n"
> + "meas_digest_valid=%x\n"
> + "all_request_redirect=%x\n"
> + "bind_p2p=%x\n"
> + "lock_msix=%x\n"
> + "no_fw_update=%x\n"
> + "cache_line_size=%d\n"
> + "algos=%#llx:%s\n"
> + "report_counter=%lld\n"
> + ,
> + ret,
> + ts.state, tdisp_state_to_str(ts.state),
> + ts.meas_digest_fresh,
> + ts.meas_digest_valid,
> + ts.all_request_redirect,
> + ts.bind_p2p,
> + ts.lock_msix,
> + ts.no_fw_update,
> + ts.cache_line_size,
> + ts.spdm_algos, spdm_algos_to_str(ts.spdm_algos, algos, sizeof(algos) - 1),
> + ts.intf_report_counter);
> +
> + n += snprintf(buf + n, PAGE_SIZE - n, "Certs digest: ");
> + m = hex_dump_to_buffer(ts.certs_digest, sizeof(ts.certs_digest), 32, 1,
> + buf + n, PAGE_SIZE - n, false);
> + n += min(PAGE_SIZE - n, m);
> + n += snprintf(buf + n, PAGE_SIZE - n, "...\nMeasurements digest: ");
> + m = hex_dump_to_buffer(ts.meas_digest, sizeof(ts.meas_digest), 32, 1,
> + buf + n, PAGE_SIZE - n, false);
> + n += min(PAGE_SIZE - n, m);
> + n += snprintf(buf + n, PAGE_SIZE - n, "...\nInterface report digest: ");
> + m = hex_dump_to_buffer(ts.interface_report_digest, sizeof(ts.interface_report_digest),
> + 32, 1, buf + n, PAGE_SIZE - n, false);
> + n += min(PAGE_SIZE - n, m);
> + n += snprintf(buf + n, PAGE_SIZE - n, "...\n");
More sysfs expectation violations...
Let's start working on what the Plumbers feedback to Lukas on his
attempt to export PCI CMA device evidence through sysfs means for the
TSM side. I do not expect it will all be strictly reusable but the
transport and some record formats should be unified. Specifically I want
to start the discussion about collaboration and differences among
PCI-CMA-netlink and PCI-TSM-netlink. For example, device measurements
are ostensibly common, but interface reports are unique to the TSM flow.
next prev parent reply other threads:[~2025-03-14 1:14 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 11:09 [RFC PATCH v2 00/22] TSM: Secure VFIO, TDISP, SEV TIO Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 01/22] pci/doe: Define protocol types and make those public Alexey Kardashevskiy
2025-04-15 20:15 ` Bjorn Helgaas
2025-02-18 11:09 ` [RFC PATCH v2 02/22] PCI/IDE: Fixes to make it work on AMD SNP-SEV Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 03/22] PCI/IDE: Init IDs on all IDE streams beforehand Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 04/22] iommu/amd: Report SEV-TIO support Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 05/22] crypto: ccp: Enable SEV-TIO feature in the PSP when supported Alexey Kardashevskiy
2025-03-22 11:50 ` Francesco Lavra
2025-03-26 4:26 ` Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 06/22] KVM: X86: Define tsm_get_vmid Alexey Kardashevskiy
2025-03-13 1:51 ` Dan Williams
2025-03-13 4:31 ` Alexey Kardashevskiy
2025-03-13 19:09 ` Dan Williams
2025-03-14 3:28 ` Alexey Kardashevskiy
2025-04-24 3:37 ` Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 07/22] coco/tsm: Add tsm and tsm-host modules Alexey Kardashevskiy
2025-03-14 1:14 ` Dan Williams [this message]
2025-05-14 18:39 ` Zhi Wang
2025-05-29 5:30 ` Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 08/22] pci/tsm: Add PCI driver for TSM Alexey Kardashevskiy
2025-04-15 20:25 ` Bjorn Helgaas
2025-02-18 11:09 ` [RFC PATCH v2 09/22] crypto/ccp: Implement SEV TIO firmware interface Alexey Kardashevskiy
2025-03-23 11:35 ` Francesco Lavra
2025-02-18 11:09 ` [RFC PATCH v2 10/22] KVM: SVM: Add uAPI to change RMP for MMIO Alexey Kardashevskiy
2025-03-15 0:08 ` Dan Williams
2025-03-27 5:00 ` Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 11/22] KVM: SEV: Add TIO VMGEXIT Alexey Kardashevskiy
2025-02-18 11:09 ` [RFC PATCH v2 12/22] iommufd: Allow mapping from guest_memfd Alexey Kardashevskiy
2025-02-18 14:16 ` Jason Gunthorpe
2025-02-18 23:35 ` Alexey Kardashevskiy
2025-02-18 23:51 ` Jason Gunthorpe
2025-02-19 0:43 ` Alexey Kardashevskiy
2025-02-19 13:35 ` Jason Gunthorpe
2025-02-19 20:23 ` Michael Roth
2025-02-19 20:37 ` Jason Gunthorpe
2025-02-19 21:30 ` Michael Roth
2025-02-20 0:57 ` Jason Gunthorpe
2025-03-13 4:51 ` Alexey Kardashevskiy
2025-03-19 17:40 ` Jason Gunthorpe
2025-02-20 2:29 ` Alexey Kardashevskiy
2025-02-18 11:10 ` [RFC PATCH v2 13/22] iommufd: amd-iommu: Add vdevice support Alexey Kardashevskiy
2025-04-01 16:11 ` Jason Gunthorpe
2025-04-10 6:39 ` Alexey Kardashevskiy
2025-04-10 8:43 ` Tian, Kevin
2025-04-10 13:05 ` Jason Gunthorpe
2025-04-14 4:17 ` Alexey Kardashevskiy
2025-02-18 11:10 ` [RFC PATCH v2 14/22] iommufd: Add TIO calls Alexey Kardashevskiy
2025-02-25 9:00 ` Xu Yilun
2025-02-26 0:12 ` Alexey Kardashevskiy
2025-02-26 10:49 ` Xu Yilun
2025-02-26 13:12 ` Jason Gunthorpe
2025-02-27 0:33 ` Alexey Kardashevskiy
2025-03-01 0:32 ` Jason Gunthorpe
2025-03-05 3:09 ` Alexey Kardashevskiy
2025-03-05 19:18 ` Jason Gunthorpe
2025-02-27 3:59 ` Xu Yilun
2025-03-01 0:37 ` Jason Gunthorpe
2025-03-03 5:32 ` Xu Yilun
2025-03-05 19:28 ` Jason Gunthorpe
2025-03-06 6:47 ` Xu Yilun
2025-03-06 18:26 ` Jason Gunthorpe
2025-03-07 6:49 ` Xu Yilun
2025-03-07 2:19 ` Alexey Kardashevskiy
2025-03-07 15:17 ` Jason Gunthorpe
2025-03-12 10:41 ` Suzuki K Poulose
2025-03-12 1:11 ` Xu Yilun
2025-02-26 13:08 ` Jason Gunthorpe
2025-03-15 1:11 ` Dan Williams
2025-03-17 2:32 ` Alexey Kardashevskiy
2025-04-01 15:53 ` Jason Gunthorpe
2025-03-13 11:01 ` Xu Yilun
2025-03-14 2:49 ` Alexey Kardashevskiy
2025-03-28 5:27 ` Aneesh Kumar K.V
2025-04-01 16:03 ` Jason Gunthorpe
2025-04-07 11:40 ` Aneesh Kumar K.V
2025-04-07 16:40 ` Jason Gunthorpe
2025-04-01 16:12 ` Jason Gunthorpe
2025-04-03 8:39 ` Alexey Kardashevskiy
2025-02-18 11:10 ` [RFC PATCH v2 15/22] KVM: X86: Handle private MMIO as shared Alexey Kardashevskiy
2025-05-15 8:18 ` Zhi Wang
2025-05-29 5:30 ` Alexey Kardashevskiy
2025-02-18 11:10 ` [RFC PATCH v2 16/22] coco/tsm: Add tsm-guest module Alexey Kardashevskiy
2025-04-05 17:15 ` Francesco Lavra
2025-02-18 11:10 ` [RFC PATCH v2 17/22] resource: Mark encrypted MMIO resource on validation Alexey Kardashevskiy
2025-04-05 18:19 ` Francesco Lavra
2025-02-18 11:10 ` [RFC PATCH v2 18/22] coco/sev-guest: Implement the guest support for SEV TIO Alexey Kardashevskiy
2025-04-07 11:05 ` Francesco Lavra
2025-02-18 11:10 ` [RFC PATCH v2 19/22] RFC: pci: Add BUS_NOTIFY_PCI_BUS_MASTER event Alexey Kardashevskiy
2025-04-15 20:26 ` Bjorn Helgaas
2025-02-18 11:10 ` [RFC PATCH v2 20/22] sev-guest: Stop changing encrypted page state for TDISP devices Alexey Kardashevskiy
2025-02-27 16:01 ` Borislav Petkov
2025-02-18 11:10 ` [RFC PATCH v2 21/22] pci: Allow encrypted MMIO mapping via sysfs Alexey Kardashevskiy
2025-04-15 20:28 ` Bjorn Helgaas
2025-02-18 11:10 ` [RFC PATCH v2 22/22] pci: Define pci_iomap_range_encrypted Alexey Kardashevskiy
2025-04-15 20:30 ` Bjorn Helgaas
2025-02-27 15:48 ` [RFC PATCH v2 00/22] TSM: Secure VFIO, TDISP, SEV TIO Borislav Petkov
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=67d382f43dc5d_201f02945a@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=ashish.kalra@amd.com \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dionnaglaze@google.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=michael.roth@amd.com \
--cc=nicolinc@nvidia.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=steven.sistare@oracle.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=suzuki.poulose@arm.com \
--cc=thomas.lendacky@amd.com \
--cc=vasant.hegde@amd.com \
--cc=x86@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yilun.xu@linux.intel.com \
--cc=zhiw@nvidia.com \
/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;
as well as URLs for NNTP newsgroup(s).