From: Bjorn Helgaas <helgaas@kernel.org>
To: Srinath Mannam <srinath.mannam@broadcom.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Ray Jui <rjui@broadcom.com>,
Andrew Murray <andrew.murray@arm.com>,
bcm-kernel-feedback-list@broadcom.com, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Bharat Gooty <bharat.gooty@broadcom.com>
Subject: Re: [PATCH 1/3] PCI: iproc: fix out of bound array access
Date: Thu, 26 Mar 2020 14:48:10 -0500 [thread overview]
Message-ID: <20200326194810.GA11112@google.com> (raw)
In-Reply-To: <1585206447-1363-2-git-send-email-srinath.mannam@broadcom.com>
Change subject to match convention, e.g.,
PCI: iproc: Fix out-of-bound array accesses
On Thu, Mar 26, 2020 at 12:37:25PM +0530, Srinath Mannam wrote:
> From: Bharat Gooty <bharat.gooty@broadcom.com>
>
> Declare the full size array for all revisions of PAX register sets
> to avoid potentially out of bound access of the register array
> when they are being initialized in the 'iproc_pcie_rev_init'
> function.
s/the 'iproc_pcie_rev_init' function/iproc_pcie_rev_init()/
It's outside the scope of this patch, but I'm not really a fan of the
pcie->reg_offsets[] scheme this driver uses to deal with these
differences. There usually seems to be *something* that keeps the
driver from referencing registers that don't exist, but it doesn't
seem like the mechanism is very consistent or robust:
- IPROC_PCIE_LINK_STATUS is implemented by PAXB but not PAXC.
iproc_pcie_check_link() avoids using it if "ep_is_internal", which
is set for PAXC and PAXC_V2. Not an obvious connection.
- IPROC_PCIE_CLK_CTRL is implemented for PAXB and PAXC_V1, but not
PAXC_V2. iproc_pcie_perst_ctrl() avoids using it ep_is_internal",
so it *doesn't* use it for PAXC_V1, which does implement it.
Maybe a bug, maybe intentional; I can't tell.
- IPROC_PCIE_INTX_EN is only implemented by PAXB (not PAXC), but
AFAICT, we always call iproc_pcie_enable() and rely on
iproc_pcie_write_reg() silently drop the write to it on PAXC.
- IPROC_PCIE_OARR0 is implemented by PAXB and PAXB_V2 and used by
iproc_pcie_map_ranges(), which is called if "need_ob_cfg", which
is set if there's a "brcm,pcie-ob" DT property. No clear
connection to PAXB.
I think it would be more readable if we used a single variant
identifier consistently, e.g., the "pcie->type" already used in
iproc_pcie_msi_steer(), or maybe a set of variant-specific function
pointers as pcie-qcom.c does.
> Fixes: 06324ede76cdf ("PCI: iproc: Improve core register population")
> Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
> ---
> drivers/pci/controller/pcie-iproc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 0a468c7..6972ca4 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -307,7 +307,7 @@ enum iproc_pcie_reg {
> };
>
> /* iProc PCIe PAXB BCMA registers */
> -static const u16 iproc_pcie_reg_paxb_bcma[] = {
> +static const u16 iproc_pcie_reg_paxb_bcma[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x120,
> [IPROC_PCIE_CFG_IND_DATA] = 0x124,
> @@ -318,7 +318,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
> };
>
> /* iProc PCIe PAXB registers */
> -static const u16 iproc_pcie_reg_paxb[] = {
> +static const u16 iproc_pcie_reg_paxb[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x120,
> [IPROC_PCIE_CFG_IND_DATA] = 0x124,
> @@ -334,7 +334,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
> };
>
> /* iProc PCIe PAXB v2 registers */
> -static const u16 iproc_pcie_reg_paxb_v2[] = {
> +static const u16 iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x120,
> [IPROC_PCIE_CFG_IND_DATA] = 0x124,
> @@ -363,7 +363,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> };
>
> /* iProc PCIe PAXC v1 registers */
> -static const u16 iproc_pcie_reg_paxc[] = {
> +static const u16 iproc_pcie_reg_paxc[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x1f0,
> [IPROC_PCIE_CFG_IND_DATA] = 0x1f4,
> @@ -372,7 +372,7 @@ static const u16 iproc_pcie_reg_paxc[] = {
> };
>
> /* iProc PCIe PAXC v2 registers */
> -static const u16 iproc_pcie_reg_paxc_v2[] = {
> +static const u16 iproc_pcie_reg_paxc_v2[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_MSI_GIC_MODE] = 0x050,
> [IPROC_PCIE_MSI_BASE_ADDR] = 0x074,
> [IPROC_PCIE_MSI_WINDOW_SIZE] = 0x078,
> --
> 2.7.4
>
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Srinath Mannam <srinath.mannam@broadcom.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Bharat Gooty <bharat.gooty@broadcom.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
bcm-kernel-feedback-list@broadcom.com,
Ray Jui <rjui@broadcom.com>,
Andrew Murray <andrew.murray@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] PCI: iproc: fix out of bound array access
Date: Thu, 26 Mar 2020 14:48:10 -0500 [thread overview]
Message-ID: <20200326194810.GA11112@google.com> (raw)
In-Reply-To: <1585206447-1363-2-git-send-email-srinath.mannam@broadcom.com>
Change subject to match convention, e.g.,
PCI: iproc: Fix out-of-bound array accesses
On Thu, Mar 26, 2020 at 12:37:25PM +0530, Srinath Mannam wrote:
> From: Bharat Gooty <bharat.gooty@broadcom.com>
>
> Declare the full size array for all revisions of PAX register sets
> to avoid potentially out of bound access of the register array
> when they are being initialized in the 'iproc_pcie_rev_init'
> function.
s/the 'iproc_pcie_rev_init' function/iproc_pcie_rev_init()/
It's outside the scope of this patch, but I'm not really a fan of the
pcie->reg_offsets[] scheme this driver uses to deal with these
differences. There usually seems to be *something* that keeps the
driver from referencing registers that don't exist, but it doesn't
seem like the mechanism is very consistent or robust:
- IPROC_PCIE_LINK_STATUS is implemented by PAXB but not PAXC.
iproc_pcie_check_link() avoids using it if "ep_is_internal", which
is set for PAXC and PAXC_V2. Not an obvious connection.
- IPROC_PCIE_CLK_CTRL is implemented for PAXB and PAXC_V1, but not
PAXC_V2. iproc_pcie_perst_ctrl() avoids using it ep_is_internal",
so it *doesn't* use it for PAXC_V1, which does implement it.
Maybe a bug, maybe intentional; I can't tell.
- IPROC_PCIE_INTX_EN is only implemented by PAXB (not PAXC), but
AFAICT, we always call iproc_pcie_enable() and rely on
iproc_pcie_write_reg() silently drop the write to it on PAXC.
- IPROC_PCIE_OARR0 is implemented by PAXB and PAXB_V2 and used by
iproc_pcie_map_ranges(), which is called if "need_ob_cfg", which
is set if there's a "brcm,pcie-ob" DT property. No clear
connection to PAXB.
I think it would be more readable if we used a single variant
identifier consistently, e.g., the "pcie->type" already used in
iproc_pcie_msi_steer(), or maybe a set of variant-specific function
pointers as pcie-qcom.c does.
> Fixes: 06324ede76cdf ("PCI: iproc: Improve core register population")
> Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
> ---
> drivers/pci/controller/pcie-iproc.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
> index 0a468c7..6972ca4 100644
> --- a/drivers/pci/controller/pcie-iproc.c
> +++ b/drivers/pci/controller/pcie-iproc.c
> @@ -307,7 +307,7 @@ enum iproc_pcie_reg {
> };
>
> /* iProc PCIe PAXB BCMA registers */
> -static const u16 iproc_pcie_reg_paxb_bcma[] = {
> +static const u16 iproc_pcie_reg_paxb_bcma[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x120,
> [IPROC_PCIE_CFG_IND_DATA] = 0x124,
> @@ -318,7 +318,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
> };
>
> /* iProc PCIe PAXB registers */
> -static const u16 iproc_pcie_reg_paxb[] = {
> +static const u16 iproc_pcie_reg_paxb[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x120,
> [IPROC_PCIE_CFG_IND_DATA] = 0x124,
> @@ -334,7 +334,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
> };
>
> /* iProc PCIe PAXB v2 registers */
> -static const u16 iproc_pcie_reg_paxb_v2[] = {
> +static const u16 iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x120,
> [IPROC_PCIE_CFG_IND_DATA] = 0x124,
> @@ -363,7 +363,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> };
>
> /* iProc PCIe PAXC v1 registers */
> -static const u16 iproc_pcie_reg_paxc[] = {
> +static const u16 iproc_pcie_reg_paxc[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_CLK_CTRL] = 0x000,
> [IPROC_PCIE_CFG_IND_ADDR] = 0x1f0,
> [IPROC_PCIE_CFG_IND_DATA] = 0x1f4,
> @@ -372,7 +372,7 @@ static const u16 iproc_pcie_reg_paxc[] = {
> };
>
> /* iProc PCIe PAXC v2 registers */
> -static const u16 iproc_pcie_reg_paxc_v2[] = {
> +static const u16 iproc_pcie_reg_paxc_v2[IPROC_PCIE_MAX_NUM_REG] = {
> [IPROC_PCIE_MSI_GIC_MODE] = 0x050,
> [IPROC_PCIE_MSI_BASE_ADDR] = 0x074,
> [IPROC_PCIE_MSI_WINDOW_SIZE] = 0x078,
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-26 19:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 7:07 [PATCH 0/3] PCI: iproc: Add fixes to pcie iproc Srinath Mannam
2020-03-26 7:07 ` Srinath Mannam
2020-03-26 7:07 ` [PATCH 1/3] PCI: iproc: fix out of bound array access Srinath Mannam
2020-03-26 7:07 ` Srinath Mannam
2020-03-26 19:48 ` Bjorn Helgaas [this message]
2020-03-26 19:48 ` Bjorn Helgaas
2020-03-26 20:27 ` Ray Jui
2020-03-26 20:27 ` Ray Jui
2020-03-26 20:48 ` Bjorn Helgaas
2020-03-26 20:48 ` Bjorn Helgaas
2020-03-30 17:04 ` Ray Jui
2020-03-30 17:04 ` Ray Jui
2020-03-26 7:07 ` [PATCH 2/3] PCI: iproc: fix invalidating PAXB address mapping Srinath Mannam
2020-03-26 7:07 ` Srinath Mannam
2020-03-26 15:28 ` Bjorn Helgaas
2020-03-26 15:28 ` Bjorn Helgaas
2020-03-26 15:33 ` Bjorn Helgaas
2020-03-26 15:33 ` Bjorn Helgaas
2020-03-26 15:38 ` Roman Bacik
2020-03-26 15:38 ` Roman Bacik
2020-03-26 7:07 ` [PATCH 3/3] PCI: iproc: Display PCIe Link information Srinath Mannam
2020-03-26 7:07 ` Srinath Mannam
2020-03-26 15:12 ` Bjorn Helgaas
2020-03-26 15:12 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200326194810.GA11112@google.com \
--to=helgaas@kernel.org \
--cc=andrew.murray@arm.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bharat.gooty@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=rjui@broadcom.com \
--cc=srinath.mannam@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.