linux-kernel - piix4-poweroff.c I/O BAR usage

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-next>] [day] [month] [year] [list]

Date:   Wed, 20 May 2020 08:57:08 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Paul Burton <paulburton@...nel.org>
Cc:     Krzysztof Wilczynski <kw@...ux.com>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: piix4-poweroff.c I/O BAR usage

Hi Paul,

This looks like it might be a bug:

  static const int piix4_pm_io_region = PCI_BRIDGE_RESOURCES;

  static int piix4_poweroff_probe(struct pci_dev *dev,
                                  const struct pci_device_id *id)
  {
          ...
          /* Request access to the PIIX4 PM IO registers */
          res = pci_request_region(dev, piix4_pm_io_region,
                                   "PIIX4 PM IO registers");

pci_request_region() takes a BAR number (0-5), but here we're passing
PCI_BRIDGE_RESOURCES (13 if CONFIG_PCI_IOV, or 7 otherwise), which is
the bridge I/O window.

I don't think this device ([8086:7113]) is a bridge, so that resource
should be empty.

Based on this spec:
https://www.intel.com/Assets/PDF/datasheet/290562.pdf,
it looks like it should be the PIIX4 power management function at
function 3, which has no standard PCI BARs but does have a PMBA (Power
Management Base Address) at 0x40 and an SMBBA (SMBus Base Address) at
0x90 in config space.

I suppose on an ACPI system the regions described by PMBA and SMBBA
might be described via ACPI, since they're not discoverable by
standard PCI enumeration?  Pretty sure you don't have ACPI on MIPS
though.

Maybe the driver should read PMBA and SMBBA and reserve those regions
by hand with request_region()?

Bjorn