linux-kernel - [PATCH] PCI: Warn about MEM resource size being too big

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:   Mon, 30 Mar 2020 17:19:47 -0700
From:   Alan Mikhak <alan.mikhak@...ive.com>
To:     linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
        jingoohan1@...il.com, gustavo.pimentel@...opsys.com,
        lorenzo.pieralisi@....com, amurray@...goodpenguin.co.uk,
        bhelgaas@...gle.com, kishon@...com, paul.walmsley@...ive.com
Cc:     Alan Mikhak <alan.mikhak@...ive.com>
Subject: [PATCH] PCI: Warn about MEM resource size being too big

Output a warning for MEM resource size with
non-zero upper 32-bits.

ATU programming functions limit the size of
the translated region to 4GB by using a u32 size
parameter. Function dw_pcie_prog_outbound_atu()
does not program the upper 32-bit ATU limit
register. This may result in undefined behavior
for resource sizes with non-zero upper 32-bits.

For example, a 128GB address space starting at
physical CPU address of 0x2000000000 with size of
0x2000000000 needs the following values programmed
into the lower and upper 32-bit limit registers:
 0x3fffffff in the upper 32-bit limit register
 0xffffffff in the lower 32-bit limit register

Currently, only the lower 32-bit limit register is
programmed with a value of 0xffffffff but the upper
32-bit limit register is not being programmed.
As a result, the upper 32-bit limit register remains
at its default value after reset of 0x0. This would
be a problem for a 128GB PCIe space because in
effect its size gets reduced to 4GB.

ATU programming functions can be changed to
specify a u64 size parameter for the translated
region. Along with this change, the internal
calculation of the limit address, the address of
the last byte in the translated region, needs to
change such that both the lower 32-bit and upper
32-bit limit registers can be programmed correctly.

Changing the ATU programming functions is high
impact. Without change, this issue can go
unnoticed. A warning may prompt the user to
look into possible issues.

This limitation also means that multiple ATUs
would need to be used to map larger regions.

Signed-off-by: Alan Mikhak <alan.mikhak@...ive.com>
---
 drivers/pci/controller/dwc/pcie-designware-host.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 395feb8ca051..37a8c71ef89a 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -325,6 +325,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
 	struct pci_bus *child;
 	struct pci_host_bridge *bridge;
 	struct resource *cfg_res;
+	resource_size_t mem_size;
 	u32 hdr_type;
 	int ret;

@@ -362,7 +363,10 @@ int dw_pcie_host_init(struct pcie_port *pp)
 		case IORESOURCE_MEM:
 			pp->mem = win->res;
 			pp->mem->name = "MEM";
-			pp->mem_size = resource_size(pp->mem);
+			mem_size = resource_size(pp->mem);
+			if (upper_32_bits(mem_size))
+				dev_warn(dev, "MEM resource size too big\n");
+			pp->mem_size = mem_size;
 			pp->mem_bus_addr = pp->mem->start - win->offset;
 			break;
 		case 0:
-- 
2.7.4