public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: fengchengwen <fengchengwen@huawei.com>
To: Wathsala Vithanage <wathsala.vithanage@arm.com>,
	<alex@shazbot.org>, <jgg@ziepe.ca>
Cc: <kvm@vger.kernel.org>, <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface
Date: Thu, 16 Apr 2026 09:09:50 +0800	[thread overview]
Message-ID: <41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com> (raw)
In-Reply-To: <518e5e0a-d0b2-4775-a32a-e2dc87c8ba4b@arm.com>

On 4/15/2026 9:55 PM, Wathsala Vithanage wrote:
> Hi Feng,
> 
> get_st  feature is unsafe. It allows a rogue userspace driver in device-specific
> mode to obtain steering tags for arbitrary CPUs, including ones unrelated
> to the device or its workload, enabling it to direct traffic into those CPUs’
> caches and potentially interfere with other workloads, opening doors to
> further exploits depending on other vulnerabilities.

Thank you for the follow-up and for referencing the prior RFC
discussion on this topic. I appreciate you clarifying the
historical context of the safety concerns.

I acknowledge the risks you’ve highlighted, but I believe the
risk profile in this VFIO interface is different and already
well bounded by existing design and practice:

1. VFIO device access requires elevated privileges
   A userspace process can only open a VFIO device node if it
   has sufficient privileges (typically root). This is not an
   interface for unprivileged users.

2. In the thread "[RFC v2 0/2] Retrieve tph from dmabuf for PCIe
   P2P memory access", applications can configure the steertag
   of exported dmabufs from userspace to the kernel. Kernel PCIe
   drivers (e.g., mlx5 NIC) then use these steertags and set them
   to their ST tables. Even here, userspace could set invalid
   steertags that impact GPU performance—but this model is
   basically accepted I think (refer from maillist discuss).

3. Malicious resource consumption is not unique to TPH
   A malicious thread can be created to forcibly consume CPU
   resources and bound to a specific CPU, affecting other CPUs.
   This is a general system security concern, not one specific
   to TPH GET_ST, and is addressed by existing system hardening
   and access control mechanisms—not by removing useful features.

4. GET_ST is strictly necessary for Device-Specific (DS) mode
   when no ST table is present on the device.
   For devices that do not have a dedicated ST table (a common
   scenario in many PCIe endpoints), DS mode requires userspace
   to retrieve per-CPU steering tags first, then program them
   into the device’s steering logic via other registers. Without
   GET_ST, userspace cannot obtain the required steertags to
   enable TPH DS mode at all—rendering TPH support useless for
   these devices. This is not an optional feature but a
   fundamental requirement to unlock TPH functionality for a
   large class of hardware.

Given these points—privilege restriction, existing industry
practice, general system security mitigations, and strict
functional necessity for DS mode—I believe GET_ST is reasonable
and consistent with existing VFIO security boundaries.

Thanks

> 
> That's why we dropped this capability in https://lore.kernel.org/kvm/20251013163515.16565-1-wathsala.vithanage@arm.com/
> 
> --wathsala
> 
>>   }
>>   +static int vfio_pci_tph_get_st(struct vfio_pci_core_device *vdev,
>> +                   struct vfio_device_pci_tph_op *op,
>> +                   void __user *uarg)
>> +{
>> +    struct vfio_pci_tph_entry *ents;
>> +    struct vfio_pci_tph_st st;
>> +    enum tph_mem_type mtype;
>> +    size_t size;
>> +    int i, err;
>> +
>> +    if (copy_from_user(&st, uarg, sizeof(st)))
>> +        return -EFAULT;
>> +
>> +    if (!st.count || st.count > 2048)
>> +        return -EINVAL;
>> +
>> +    size = st.count * sizeof(*ents);
>> +    ents = kvmalloc(size, GFP_KERNEL);
>> +    if (!ents)
>> +        return -ENOMEM;
>> +
>> +    if (copy_from_user(ents, uarg + sizeof(st), size)) {
>> +        err = -EFAULT;
>> +        goto out;
>> +    }
>> +
>> +    for (i = 0; i < st.count; i++) {
>> +        if (ents[i].mem_type == VFIO_PCI_TPH_MEM_TYPE_VM) {
>> +            mtype = TPH_MEM_TYPE_VM;
>> +        } else if (ents[i].mem_type == VFIO_PCI_TPH_MEM_TYPE_PM) {
>> +            mtype = TPH_MEM_TYPE_PM;
>> +        } else {
>> +            err = -EINVAL;
>> +            goto out;
>> +        }
>> +
>> +        err = pcie_tph_get_cpu_st(vdev->pdev, mtype, ents[i].cpu, &ents[i].st);
>> +        if (err)
>> +            goto out;
>> +    }
>> +
>> +    if (copy_to_user(uarg + sizeof(st), ents, size))
>> +        err = -EFAULT;
>> +
>> +out:
>> +    kvfree(ents);
>> +    return err;
>> +}
>> +
>>   static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,
>>                     void __user *uarg)
>>   {
>> @@ -1544,6 +1593,8 @@ static int vfio_pci_ioctl_tph(struct vfio_pci_core_device *vdev,
>>           return vfio_pci_tph_enable(vdev, &op, uarg + minsz);
>>       case VFIO_PCI_TPH_DISABLE:
>>           return vfio_pci_tph_disable(vdev);
>> +    case VFIO_PCI_TPH_GET_ST:
>> +        return vfio_pci_tph_get_st(vdev, &op, uarg + minsz);
>>       default:
>>           /* Other ops are not implemented yet */
>>           return -EINVAL;
> 


  reply	other threads:[~2026-04-16  1:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-15  9:09 [PATCH 0/4] vfio/pci: Add PCIe TPH support Chengwen Feng
2026-04-15  9:09 ` [PATCH 1/4] vfio/pci: Add PCIe TPH interface with capability query Chengwen Feng
2026-04-15  9:09 ` [PATCH 2/4] vfio/pci: Add PCIe TPH enable/disable support Chengwen Feng
2026-04-15  9:09 ` [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface Chengwen Feng
2026-04-15 13:55   ` Wathsala Vithanage
2026-04-16  1:09     ` fengchengwen [this message]
2026-04-16 13:40       ` Alex Williamson
2026-04-16 16:12         ` Wathsala Vithanage
2026-04-17  0:48         ` fengchengwen
2026-04-17  2:06           ` fengchengwen
2026-04-15  9:09 ` [PATCH 4/4] vfio/pci: Add PCIe TPH SET_ST interface Chengwen Feng
     [not found]   ` <e6dbfdd5-5117-4c3e-bb84-ee1e489aa38f@arm.com>
2026-04-16  1:16     ` fengchengwen

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=41d5b3ea-abe2-4583-be88-2addf6b4d394@huawei.com \
    --to=fengchengwen@huawei.com \
    --cc=alex@shazbot.org \
    --cc=jgg@ziepe.ca \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=wathsala.vithanage@arm.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