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

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: <aMPLDLYpeVXO1y6R@wunner.de>
Date: Fri, 12 Sep 2025 09:26:04 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Mario Limonciello <superm1@...nel.org>
Cc: Bjorn Helgaas <helgaas@...nel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Alan Stern <stern@...land.harvard.edu>, linux-pci@...r.kernel.org,
	linux-pm@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Oleksij Rempel <o.rempel@...gutronix.de>,
	Timo Jyrinki <timo.jyrinki@...il.com>,
	Ernst Persson <ernstp@...il.com>, Steven Harms <sjharms@...il.com>,
	James Ettle <james@...le.org.uk>, Nick Coghlan <ncoghlan@...il.com>,
	Weng Xuetian <wengxt@...il.com>,
	Andrey Rahmatullin <wrar@...r.name>,
	Boris Barbour <boris.barbour@....fr>,
	Vlastimil Zima <vlastimil.zima@...il.com>,
	David Banks <amoebae@...il.com>, Chris Moeller <kode54@...il.com>,
	Daniel Fraga <fragabr@...il.com>, Javier Marcet <jmarcet@...il.com>,
	Pavel Pisa <pisa@....felk.cvut.cz>
Subject: Re: [PATCH] PCI/PM: Move ASUS EHCI workaround out of generic code

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