linux-kernel - [PATCH 0/9] PCI: Use IORESOURCE

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, 26 Feb 2014 12:37:04 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	linux-pci@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 0/9] PCI: Use IORESOURCE_UNSET for unassigned BARs

I'm trying to unify the way we handle unassigned PCI BARs, i.e., resources
where we know the type and size, but we haven't assigned an address yet.
The PCI core and the various architectures don't really have a consistent
way of dealing with these.

Many places currently use "res->start == 0" to indicate unassigned
resources.  I don't think that's a good idea in general, because it's
possible for a resource to actually start at zero.  Zero is also a
perfectly good BAR value, especially for a host bridge that translates
addresses, so I want to support that, too.

The IORESOURCE_UNSET flag exists already, but is hardly used at all.  In
drivers/pci, we set it for an obscure error case, and clear it when
updating a BAR.  The microblaze and powerpc architectures use it the same
way I want to use it here: to indicate a resource with no assigned address.

Here's the outline of what this series does:

- Add resource_contains(): true iff r1 contains r2 (for minor cleanup)
- Make %pR print resource size, not address, when IORESOURCE_UNSET
- Stop advertising pci_find_parent_resource() for use in allocation
- Mark PCI resources IORESOURCE_UNSET when BIOS left decoding disabled
- Mark PCI resources IORESOURCE_UNSET while we're trying to assign addresses
- Don't enable PCI decoding when no address has been assigned to BARs

It might be too aggressive to ignore the initial value of a BAR and try to
reassign it when the BIOS left decoding disabled.  If the BIOS left
decoding *enabled*, we can have some confidence that the BAR value is
valid.  It's possible the BAR is also valid even if the BIOS turned off
decoding.  We could conceivably try to use BAR values that are inside
upstream bridge windows, even if the BAR was initially disabled.  But this
first pass just ignores the values in BARs that are disabled.

I welcome any comments :)

---

Bjorn Helgaas (9):
      resource: Add resource_contains()
      vsprintf: Add support for IORESOURCE_UNSET in %pR
      PCI: Remove pci_find_parent_resource() use for allocation
      PCI: Mark resources as IORESOURCE_UNSET if we can't assign them
      PCI: Don't clear IORESOURCE_UNSET when updating BAR
      PCI: Check IORESOURCE_UNSET before updating BAR
      PCI: Don't try to claim IORESOURCE_UNSET resources
      PCI: Ignore BAR contents when firmware left decoding disabled
      PCI: Don't enable decoding if BAR hasn't been assigned an address

 drivers/pci/host-bridge.c |    8 --------
 drivers/pci/pci.c         |   41 +++++++++++++++++++++++++----------------
 drivers/pci/probe.c       |    8 +++++++-
 drivers/pci/quirks.c      |    5 +++++
 drivers/pci/rom.c         |    2 ++
 drivers/pci/setup-res.c   |   37 +++++++++++++++++++++++++------------
 include/linux/ioport.h    |   12 +++++++++++-
 kernel/resource.c         |    8 ++------
 lib/vsprintf.c            |   13 +++++++++----
 9 files changed, 86 insertions(+), 48 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/