From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D40F1C52D7C for ; Wed, 21 Aug 2024 15:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Type:MIME-Version:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=TM/Evr20pKVKLJlJuZxn4oBf0wDECGY+WaRnpHIynvQ=; b=CDq1P5kk8/TBDI FyU5CCfa2KJ1XStB2uDi8gx+R8rFk9Gzgb7f+KDpaIiENoiWW4QHYWg7rHeNfeOQoLEq2WpKCtXO1 0g40ix5PyNXi68u/EWGUCyyJ+JQTtzkPiKGe7FY9Frv9yTKNkh1jgnSk2clwYZoAuZrweFxRNXUIC nLzmh4/e/XBOMKM+lUM9OglB0/yCHszzHP7gUzwgXU9ExWisTRRuceR6LQUPWzQy3AmtakDEaLdwM uZXLF69x5sWfVChsHsYcWgF7j12zUAWuUBQLq7vjLI0vP8YAegDQNDyk8x6ol41Huy5nnItZGdJoH Dhp03Xlfq3UG2a0htfpA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgnEU-00000009UkB-3DFk; Wed, 21 Aug 2024 15:26:46 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgnCc-00000009UEw-3XzD; Wed, 21 Aug 2024 15:24:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:References; bh=TM/Evr20pKVKLJlJuZxn4oBf0wDECGY+WaRnpHIynvQ=; b=h1PzpV7oI3LFq6dGiToRWmFSo4 Trxgry1O/E0qQeik+1aedu5Xctevwxd/T3z4DUBFr3glNf/XeRSeqraiW+6txZ6j/MIlq9J3CD3pY gtt956Mwt3W9Z5lt2aN9bvrSj5TCi9qnXX1RTqwEIsuh/bdjZ1f1kUFGfCw/GCRHfOXCkK/oYIjmQ OD2pbtf8m64kTPSEf7xh+4bsNHdGigD5f6BxVgXFfYPRbze/Y2jakTqR0yq4iivwEDIb2aYwVlvip CYg5j2P74wvY0nl7+LG3RtnzFgsn8DXpfDGSlhQm6WKNkz/aGiH5wkycD5t9lyLv6mRnAYYbvnC44 mmzo2gdA==; Received: from nyc.source.kernel.org ([147.75.193.91]) by desiato.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgnCZ-00000009eBe-1m4g; Wed, 21 Aug 2024 15:24:49 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id F28F7A41CCB; Wed, 21 Aug 2024 15:24:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F6A2C32786; Wed, 21 Aug 2024 15:24:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724253883; bh=1ZjtB2qfgq/kDPmIlWye3dfIwc8C55gZjyVxcfwSetA=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=TtZjkQ1JoqTb6Y/uUb/+73JdcHZH9WrH/IHzsTJfRG26ORrRRXSHBUa3Ueb/e9SOb k+YJ0KHOXTGtYG5oazohYwVwQQK3KDEf/71BUc7OXOdTJlVctngwIuzs1C7lde3MAJ pOkDSlsc+fkPkwpLUeIcPRhz8rIzG5YpUUSjE4eFZTv5Ru4EgJPTmgquBbi2iVyxUh C9U5Ua+xUG0hSc+Wj/prm44j9A3uSlbySmXCbjYORNrb9ll2z/NTmnAWCB0ivJqWDj SwHlMZ5c2nYJuioTX1efrHNcneRaN9R8CdTYDaqgpWaDSBzN320A/M3P/+osCa1kUz 7lcpXCYz5QVmQ== Date: Wed, 21 Aug 2024 10:24:41 -0500 From: Bjorn Helgaas To: Andrea della Porta Subject: Re: [PATCH 03/11] PCI: of_property: Sanitize 32 bit PCI address parsed from DT Message-ID: <20240821152441.GA222583@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b4fa91380fc4754ea80f47330c613e4f6b6592c.1724159867.git.andrea.porta@suse.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240821_162447_791408_F5130459 X-CRM114-Status: GOOD ( 28.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Lunn , Catalin Marinas , Michael Turquette , Claudiu Beznea , Eric Dumazet , Dragan Cvetic , Will Deacon , linux-clk@vger.kernel.org, linux-arch@vger.kernel.org, Rob Herring , Florian Fainelli , Lee Jones , Saravana Kannan , Broadcom internal kernel review list , linux-pci@vger.kernel.org, Jakub Kicinski , Paolo Abeni , Linus Walleij , devicetree@vger.kernel.org, Conor Dooley , Arnd Bergmann , linux-gpio@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Derek Kiernan , Stephen Boyd , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Stefan Wahren , netdev@vger.kernel.org, Krzysztof Kozlowski , "David S. Miller" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 20, 2024 at 04:36:05PM +0200, Andrea della Porta wrote: > The of_pci_set_address() function parse devicetree PCI range specifier s/parse/parses/ ? > assuming the address is 'sanitized' at the origin, i.e. without checking > whether the incoming address is 32 or 64 bit has specified in the flags. > In this way an address with no OF_PCI_ADDR_SPACE_MEM64 set in the flagss s/flagss/flags/ > could leak through and the upper 32 bits of the address will be set too, > and this violates the PCI specs stating that ion 32 bit address the upper s/ion/in/ > bit should be zero. I don't understand this code, so I'm probably missing something. It looks like the interesting path here is: of_pci_prop_ranges res = &pdev->resource[...]; for (j = 0; j < num; j++) { val64 = res[j].start; of_pci_set_address(..., val64, 0, flags, false); + if (OF_PCI_ADDR_SPACE_MEM64) + prop[1] = upper_32_bits(val64); + else + prop[1] = 0; OF_PCI_ADDR_SPACE_MEM64 tells us about the size of the PCI bus address, but the address (val64) is a CPU physical address, not a PCI bus address, so I don't understand why of_pci_set_address() should use OF_PCI_ADDR_SPACE_MEM64 to clear part of the CPU address. Add blank lines between paragraphs. > This could cause mapping translation mismatch on PCI devices (e.g. RP1) > that are expected to be addressed with a 64 bit address while advertising > a 32 bit address in the PCI config region. > Add a check in of_pci_set_address() to set upper 32 bits to zero in case > the address has no 64 bit flag set. Is this an indication of a DT error? Have you seen this cause a problem? If so, what does it look like to a user? I.e., how could a user find this patch if they saw a problem? > Signed-off-by: Andrea della Porta > --- > drivers/pci/of_property.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/of_property.c b/drivers/pci/of_property.c > index 5a0b98e69795..77865facdb4a 100644 > --- a/drivers/pci/of_property.c > +++ b/drivers/pci/of_property.c > @@ -60,7 +60,10 @@ static void of_pci_set_address(struct pci_dev *pdev, u32 *prop, u64 addr, > prop[0] |= flags | reg_num; > if (!reloc) { > prop[0] |= OF_PCI_ADDR_FIELD_NONRELOC; > - prop[1] = upper_32_bits(addr); > + if (FIELD_GET(OF_PCI_ADDR_FIELD_SS, flags) == OF_PCI_ADDR_SPACE_MEM64) > + prop[1] = upper_32_bits(addr); > + else > + prop[1] = 0; > prop[2] = lower_32_bits(addr); > } > } > -- > 2.35.3 >