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] [day] [month] [year] [list]
Message-ID:
 <SI2PR01MB4393772BA4AEF5ABF04E8F3FDC90A@SI2PR01MB4393.apcprd01.prod.exchangelabs.com>
Date: Tue, 27 Jan 2026 13:07:51 +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/27/26 2:01 AM, Jason Gunthorpe wrote:
> On Mon, Jan 26, 2026 at 05:10:18PM +0800, Wei Wang wrote:
>> 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.
> 
> No, there are not "bugs", there is a gap where a very rare and narrow
> HW configuration was not specified. The vast majority of systems don't
> even hit this gap, and when they do switches that are safe and secure
> to use with Linux do the right thing..
> 
>> The warning is intended to raise awareness for users, so they can make
>> informed decisions about continuing with this setup.
> 
> Then print warnings only in known bad cases by detecting the holes and
> evaluating the quirks database if the device malfunctions. That's
> hard, so I would just skip the print..

OK, I'll drop the warning.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ