lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a65d90f2-b6c6-4230-af52-8f676b3605c5@linux.intel.com>
Date: Thu, 24 Apr 2025 11:27:07 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Tushar Dave <tdave@...dia.com>, joro@...tes.org, will@...nel.org,
 robin.murphy@....com, kevin.tian@...el.com, jgg@...dia.com,
 yi.l.liu@...el.com, iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Cc: linux-pci@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH rc] iommu: Skip PASID validation for devices without PASID
 capability

On 4/24/25 10:06, Tushar Dave wrote:
> Generally PASID support requires ACS settings that usually create
> single device groups, but there are some niche cases where we can get
> multi-device groups and still have working PASID support. The primary
> issue is that PCI switches are not required to treat PASID tagged TLPs
> specially so appropriate ACS settings are required to route all TLPs to
> the host bridge if PASID is going to work properly.
> 
> pci_enable_pasid() does check that each device that will use PASID has
> the proper ACS settings to achieve this routing.
> 
> However, no-PASID devices can be combined with PASID capable devices
> within the same topology using non-uniform ACS settings. In this case
> the no-PASID devices may not have strict route to host ACS flags and
> end up being grouped with the PASID devices.
> 
> This configuration fails to allow use of the PASID within the iommu
> core code which wrongly checks if the no-PASID device supports PASID.
> 
> Fix this by ignoring no-PASID devices during the PASID validation. They
> will never issue a PASID TLP anyhow so they can be ignored.
> 
> Fixes: c404f55c26fc ("iommu: Validate the PASID in iommu_attach_device_pasid()")
> Cc:stable@...r.kernel.org
> Signed-off-by: Tushar Dave<tdave@...dia.com>
> ---
>   drivers/iommu/iommu.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 4f91a740c15f..e01df4c3e709 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -3440,7 +3440,13 @@ int iommu_attach_device_pasid(struct iommu_domain *domain,
>   
>   	mutex_lock(&group->mutex);
>   	for_each_group_device(group, device) {
> -		if (pasid >= device->dev->iommu->max_pasids) {
> +		/*
> +		 * Skip PASID validation for devices without PASID support
> +		 * (max_pasids = 0). These devices cannot issue transactions
> +		 * with PASID, so they don't affect group's PASID usage.
> +		 */
> +		if ((device->dev->iommu->max_pasids > 0) &&
> +		    (pasid >= device->dev->iommu->max_pasids)) {

What the iommu driver should do when set_dev_pasid is called for a non-
PASID device? The iommu driver has no sense of iommu group, hence it has
no knowledge about this device sharing an iommu group with another PASID
capable device.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ