linux-kernel - Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to pci_acs_flags

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:
 <SI2PR01MB4393D4D3E28FC1E22E3DF3CDDC93A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>
Date: Mon, 26 Jan 2026 17:10:18 +0800
From: Wei Wang <wei.w.wang@...mail.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: bhelgaas@...gle.com, akpm@...ux-foundation.org, bp@...en8.de,
 rdunlap@...radead.org, alex@...zbot.org, kevin.tian@...el.com,
 linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: Add the enhanced ACS controls check to
 pci_acs_flags_enabled()

On 1/23/26 10:51 PM, Jason Gunthorpe wrote:
> On Fri, Jan 23, 2026 at 09:49:43AM +0800, Wei Wang wrote:
>> The enhanced ACS controls introduced by PCIe Gen 5 ensures better device
>> isolation. On devices that support the PCI_ACS_ECAP capability, the
>> controls are required to be enabled properly:
>> - ACS I/O Request Blocking needs to be enabled to avoid unintended
>>    upstream I/O requests.
>> - ACS DSP and USP Memory Target Access Control needs to be set with
>>    Request Redirect or Request Blocking to ensure the Downstream and
>>    and Upstream Port memory resource ranges are not accessed by upstream
>>    memory requests.
>> - ACS Unclaimed Request Redirect needs to be enabled to ensure accesses to
>>    areas that lies within a Switch's Upstream Port memory apertures but not
>>    within any Downstream Port memory apertures get redirected.
>>
>> To maintain compatibility with legacy devices that lack PCI_ACS_ECAP
>> support, pci_acs_enabled() skips checking for the capability and logs a
>> warning to indicate that isolation may be incomplete.
> 
> That's every existing system, please don't do that.
> 
> The issue with ECAP is the way PCI SIG re-defined what Linux has been
> doing forever as unsafe.

My viewpoint is that there are known bugs with the legacy ACS defined in 
PCIe Gen 4, and PCIe Gen 5 attempts to address them through new controls 
in the Enhanced Capability (ECAP). From the Linux perspective, we just 
need to adapt accordingly to ensure 'better' isolation.

That's why I was considering adding a warning log to inform users that 
these legacy bugs may still be present. In practice, these issues 
primarily affect virtual machine scenarios. The host kernel isn't 
impacted as the USP/DSP holes and MMIOs are marked as reserved regions, 
which are skipped during IOVA allocation.

The warning is intended to raise awareness for users, so they can make 
informed decisions about continuing with this setup.

> 
> Jason
> 
>>
>> Signed-off-by: Wei Wang <wei.w.wang@...mail.com>
>> ---
>>   drivers/pci/pci.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 67 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index c4cf835ec8ba..ff974ced90aa 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3527,6 +3527,56 @@ void pci_configure_ari(struct pci_dev *dev)
>>   	}
>>   }
>>   
>> +static bool pci_dev_has_memory_bars(struct pci_dev *pdev)
>> +{
>> +	int i;
>> +
>> +	for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
>> +		if (pci_resource_flags(pdev, i) & IORESOURCE_MEM)
>> +			return true;
>> +	}
>> +
>> +	return false;
>> +}
>> +
>> +static bool pci_acs_ecap_enabled(struct pci_dev *pdev, u16 ctrl)
>> +{
>> +	struct pci_dev *usp_pdev = pci_upstream_bridge(pdev);
>> +	u16 mask = PCI_ACS_DMAC_RB | PCI_ACS_DMAC_RR;
>> +
>> +	/*
>> +	 * For ACS DSP/USP Memory Target Access Control, either Request
>> +	 * Redirect or Request Blocking must be enabled to enforce isolation.
>> +	 * According to PCIe spec 6.2, the DSP Memory Target Access is
>> +	 * applicable to both Root Ports and Switch Upstream Ports that have
>> +	 * applicable Memory BAR space to protect. So if the device does not
>> +	 * have a Memory BAR, it skips the check.
>> +	 */
> 
> This doesn't make sense, the special cases PCI sig clarified only have
> to do with switches that have MMIO on their USP/DSP and a case where
> the DSP aperture isn't covered by all the USPs.
> 

Do you have a link to the clarification from PCI sig?

In PCIe Spec 7.0, the ACS DSP Memory Target Access Control field is 
still explicitly required for Root Ports and Switch Downstream Ports 
when the ACS Enhanced Capability bit is set

For USP Memory Target Access Control, the spec does not list Root Ports 
as requiring this field.

> These tests shouldn't be done outside a usp/dsp context.

It might not be difficult to tweak the implementation for this (just 
skip Root Port in the check).
(Curious to read the clarification from PCI sig first)

> 
> You can look at what I drafted earlier here:
> 
> https://lore.kernel.org/all/0-v3-8827cc7fc4e0+23f-pcie_switch_groups_jgg@nvidia.com/

IIUC the implementation also applied the DSP Memory Target Access 
Control check to the Root Port?