Re: [PATCH] PCI/PM: Move ASUS EHCI workaround out of generic code

[Lukas Wunner <lukas@wunner.de>]

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