Re: [PATCH 3/4] vfio/pci: Add PCIe TPH GET_ST interface

[Wathsala Vithanage <wathsala.vithanage@arm.com>]

On 4/16/26 08:40, Alex Williamson wrote:
> On Thu, 16 Apr 2026 09:09:50 +0800
> fengchengwen <fengchengwen@huawei.com> wrote:
>
>> 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.
> This argument is NOT helping your cause.  This is not the usage model
> we design for.  VFIO usage requires that privileges be granted to a
> user, in the form of device ACL access and locked memory, but does not
> generally require elevated privileges beyond that, or otherwise grant
> the user authority beyond the scope of the device.  The root use case
> may be typical for you, but is not required for many other typical use
> cases, such as device assignment to VMs.
>   
>> 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).
> It's an RFC.  It's bold to claim that it's nearly accepted.
>
>> 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.
> You're conflating process abuse of a CPU to a potential side-channel
> DMA attach from a device.  What *existing* hardening protects against
> the latter?
>
>> 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.
> Unlocking a hardware feature does not give you authority to ignore the
> security implications of that feature.  Thanks,
>
> Alex


First vfio-TPH RFC captures some of the risks
https://lore.kernel.org/kvm/20250221224638.1836909-1-wathsala.vithanage@arm.com/

--wathsala