On Thu, Sep 11, 2025 at 08:34:56AM -0500, Mario Limonciello wrote: > On 9/11/25 8:11 AM, Lukas Wunner wrote: > > pci_disable_device() does not clear I/O and Memory Space Enable, although > > its name suggests otherwise. The kernel has never disabled these bits > > once they're enabled. Doing so would avoid the need for the quirk, but it > > is unclear what will break if this fundamental behavior is changed. > > It's too late for this cycle to do so, but how would you feel about making > this change at the start of the next cycle so it had a whole cycle to bake > in linux-next and see if there is a problem in doing so? I can look into it. The change could be justified as a security enhancement to prevent unauthorized traffic between devices through peer-to-peer transactions. pci_disable_device() was introduced with v2.4.3.5 in 2002: https://git.kernel.org/tglx/history/c/9102e0eb3e9e I suspect back in the day, clearing Bus Master Enable seemed sufficient because the only concern was to prevent DMA (and by extension MSIs) from broken devices. Attacks *between* devices were probably not considered realistic. ACS is meant to prevent such attacks, but is an optional capability and might be configured incorrectly. A zero trust, defense in depth approach as is common today requires not leaving doors open without need. If the kernel would clear Memory Space Enable, a malicious device could not re-enable it on its own because "propagation of Configuration Requests from Downstream to Upstream as well as peer-to-peer are not supported" (PCIe r7.0 sec 7.3.3). It seemed too risky to make such a sweeping change only to get rid of the EHCI quirk. The present patch is meant as a low-risk refactoring, but we can consider clearing IO + Memory Space Enable as a long-term solution. I've cc'ed all the people who reported issues with ASUS machines back in 2012 in the hope that some of them still have the (now 13 years old) hardware to test the patch. They might also be able to test whether the long-term change doesn't regress anything. Thanks, Lukas
