All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lokesh Vutla <lokeshvutla@ti.com>
To: Punit Agrawal <punit.agrawal@arm.com>, <linux-kernel@vger.kernel.org>
Cc: <marc.zyngier@arm.com>, <linux-arm-kernel@lists.infradead.org>,
	"Menon, Nishanth" <nm@ti.com>
Subject: Re: [3/3] irqchip/gic-v3: Bounds check redistributor accesses
Date: Tue, 13 Mar 2018 19:08:46 +0530	[thread overview]
Message-ID: <28f9c1cd-e1df-f4db-32b4-c9ca0f0f256a@ti.com> (raw)
In-Reply-To: <20171011094148.15674-4-punit.agrawal@arm.com>

Hi All,

On Wednesday 11 October 2017 03:11 PM, Punit Agrawal wrote:
> The kernel crashes while iterating over a redistributor that is
> in-correctly sized by the platform firmware or doesn't contain the last
> record.
> 
> Prevent the crash by checking accesses against the size of the region
> provided by the firmware. While we are at it, warn the user about
> incorrect region size.
> 
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>

Sorry to bring up an old thread. Just wanted to check what is the status
on this series.

This will also be useful when we try to boot linux + hypervisor with
less number of cores than the SoC supports. For example:
- SoC has 4 cores and Linux tries to boot with 2 cores.
- then a type-2 hypervisor gets installed.
- Hypervisor tries to boot a VM with linux on core 1.

Now the VM boot will fail while it iterates over all the GICR regions
till GICR_TYPER is found. Hypervisor will trap any accesses to GICR
regions of any invalid cpus(cpu 2, cpu 3 in this case).

If the $patch is not the right approach, can you suggest on how to
handle the above scenario?

Thanks and regards,
Lokesh

> ---
>  drivers/irqchip/irq-gic-v3.c | 48 ++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 40 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 881d327c53fa..754d936c95e5 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -429,11 +429,21 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  	int i;
>  
>  	for (i = 0; i < gic_data.nr_redist_regions; i++) {
> -		void __iomem *ptr = gic_data.redist_regions[i].redist_base;
>  		struct resource *res = &gic_data.redist_regions[i].res;
> -		u64 typer;
> +		void __iomem *ptr, *base;
> +		u64 typer, size, stride;
>  		u32 reg;
>  
> +		ptr = base = gic_data.redist_regions[i].redist_base;
> +		size = resource_size(res);
> +
> +		stride = gic_data.redist_stride ?: SZ_64K * 2;
> +		if (ptr + stride > base + size) {
> +			pr_warn("Insufficient size for redistributor region @%llx. Skipping\n",
> +				res->start);
> +			continue;
> +		}
> +
>  		reg = readl_relaxed(ptr + GICR_PIDR2) & GIC_PIDR2_ARCH_MASK;
>  		if (reg != GIC_PIDR2_ARCH_GICv3 &&
>  		    reg != GIC_PIDR2_ARCH_GICv4) { /* We're in trouble... */
> @@ -442,7 +452,28 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  		}
>  
>  		do {
> +			/*
> +			 * We can access GICR_TYPER as we have already
> +			 * checked that we have atleast 128kB or
> +			 * redist_stride
> +			 */
>  			typer = gic_read_typer(ptr + GICR_TYPER);
> +			if (!gic_data.redist_stride &&
> +			    (typer & GICR_TYPER_VLPIS)) {
> +				/* VLPI_base + reserved page */
> +				stride += SZ_64K * 2;
> +
> +				/*
> +				 * We are larger than we thought, do
> +				 * we still fit?
> +				 */
> +				if (ptr + stride > base + size) {
> +					pr_warn("No last record found in redistributor region @%llx\n",
> +						gic_data.redist_regions[i].res.start);
> +					break;
> +				}
> +			}
> +
>  			ret = fn(gic_data.redist_regions + i, ptr);
>  			if (!ret)
>  				return 0;
> @@ -450,12 +481,13 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  			if (gic_data.redist_regions[i].single_redist)
>  				break;
>  
> -			if (gic_data.redist_stride) {
> -				ptr += gic_data.redist_stride;
> -			} else {
> -				ptr += SZ_64K * 2; /* Skip RD_base + SGI_base */
> -				if (typer & GICR_TYPER_VLPIS)
> -					ptr += SZ_64K * 2; /* Skip VLPI_base + reserved page */
> +			ptr += stride;
> +
> +			stride = gic_data.redist_stride ?: SZ_64K * 2;
> +			if (ptr + stride > base + size) {
> +				pr_warn("No last record found in redistributor region @%llx\n",
> +					gic_data.redist_regions[i].res.start);
> +				break;
>  			}
>  		} while (!(typer & GICR_TYPER_LAST));
>  	}
> 

WARNING: multiple messages have this Message-ID (diff)
From: lokeshvutla@ti.com (Lokesh Vutla)
To: linux-arm-kernel@lists.infradead.org
Subject: [3/3] irqchip/gic-v3: Bounds check redistributor accesses
Date: Tue, 13 Mar 2018 19:08:46 +0530	[thread overview]
Message-ID: <28f9c1cd-e1df-f4db-32b4-c9ca0f0f256a@ti.com> (raw)
In-Reply-To: <20171011094148.15674-4-punit.agrawal@arm.com>

Hi All,

On Wednesday 11 October 2017 03:11 PM, Punit Agrawal wrote:
> The kernel crashes while iterating over a redistributor that is
> in-correctly sized by the platform firmware or doesn't contain the last
> record.
> 
> Prevent the crash by checking accesses against the size of the region
> provided by the firmware. While we are at it, warn the user about
> incorrect region size.
> 
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>

Sorry to bring up an old thread. Just wanted to check what is the status
on this series.

This will also be useful when we try to boot linux + hypervisor with
less number of cores than the SoC supports. For example:
- SoC has 4 cores and Linux tries to boot with 2 cores.
- then a type-2 hypervisor gets installed.
- Hypervisor tries to boot a VM with linux on core 1.

Now the VM boot will fail while it iterates over all the GICR regions
till GICR_TYPER is found. Hypervisor will trap any accesses to GICR
regions of any invalid cpus(cpu 2, cpu 3 in this case).

If the $patch is not the right approach, can you suggest on how to
handle the above scenario?

Thanks and regards,
Lokesh

> ---
>  drivers/irqchip/irq-gic-v3.c | 48 ++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 40 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 881d327c53fa..754d936c95e5 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -429,11 +429,21 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  	int i;
>  
>  	for (i = 0; i < gic_data.nr_redist_regions; i++) {
> -		void __iomem *ptr = gic_data.redist_regions[i].redist_base;
>  		struct resource *res = &gic_data.redist_regions[i].res;
> -		u64 typer;
> +		void __iomem *ptr, *base;
> +		u64 typer, size, stride;
>  		u32 reg;
>  
> +		ptr = base = gic_data.redist_regions[i].redist_base;
> +		size = resource_size(res);
> +
> +		stride = gic_data.redist_stride ?: SZ_64K * 2;
> +		if (ptr + stride > base + size) {
> +			pr_warn("Insufficient size for redistributor region @%llx. Skipping\n",
> +				res->start);
> +			continue;
> +		}
> +
>  		reg = readl_relaxed(ptr + GICR_PIDR2) & GIC_PIDR2_ARCH_MASK;
>  		if (reg != GIC_PIDR2_ARCH_GICv3 &&
>  		    reg != GIC_PIDR2_ARCH_GICv4) { /* We're in trouble... */
> @@ -442,7 +452,28 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  		}
>  
>  		do {
> +			/*
> +			 * We can access GICR_TYPER as we have already
> +			 * checked that we have atleast 128kB or
> +			 * redist_stride
> +			 */
>  			typer = gic_read_typer(ptr + GICR_TYPER);
> +			if (!gic_data.redist_stride &&
> +			    (typer & GICR_TYPER_VLPIS)) {
> +				/* VLPI_base + reserved page */
> +				stride += SZ_64K * 2;
> +
> +				/*
> +				 * We are larger than we thought, do
> +				 * we still fit?
> +				 */
> +				if (ptr + stride > base + size) {
> +					pr_warn("No last record found in redistributor region @%llx\n",
> +						gic_data.redist_regions[i].res.start);
> +					break;
> +				}
> +			}
> +
>  			ret = fn(gic_data.redist_regions + i, ptr);
>  			if (!ret)
>  				return 0;
> @@ -450,12 +481,13 @@ static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem *))
>  			if (gic_data.redist_regions[i].single_redist)
>  				break;
>  
> -			if (gic_data.redist_stride) {
> -				ptr += gic_data.redist_stride;
> -			} else {
> -				ptr += SZ_64K * 2; /* Skip RD_base + SGI_base */
> -				if (typer & GICR_TYPER_VLPIS)
> -					ptr += SZ_64K * 2; /* Skip VLPI_base + reserved page */
> +			ptr += stride;
> +
> +			stride = gic_data.redist_stride ?: SZ_64K * 2;
> +			if (ptr + stride > base + size) {
> +				pr_warn("No last record found in redistributor region @%llx\n",
> +					gic_data.redist_regions[i].res.start);
> +				break;
>  			}
>  		} while (!(typer & GICR_TYPER_LAST));
>  	}
> 

  reply	other threads:[~2018-03-13 13:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11  9:41 [PATCH 0/3] GICv3: Bounds check redistributor accesses Punit Agrawal
2017-10-11  9:41 ` Punit Agrawal
2017-10-11  9:41 ` [PATCH 1/3] irqchip/gic-v3: Use resource structure to store redistributor regions Punit Agrawal
2017-10-11  9:41   ` Punit Agrawal
2017-10-11  9:41 ` [PATCH 2/3] irqchip/gic-v3: Report firmwware provided address in case of error Punit Agrawal
2017-10-11  9:41   ` Punit Agrawal
2017-10-11  9:41 ` [PATCH 3/3] irqchip/gic-v3: Bounds check redistributor accesses Punit Agrawal
2017-10-11  9:41   ` Punit Agrawal
2018-03-13 13:38   ` Lokesh Vutla [this message]
2018-03-13 13:38     ` [3/3] " Lokesh Vutla
2018-03-13 14:21     ` Marc Zyngier
2018-03-13 14:21       ` Marc Zyngier
2018-03-13 18:49       ` Nishanth Menon
2018-03-13 18:49         ` Nishanth Menon
2018-03-13 20:19         ` Marc Zyngier
2018-03-13 20:19           ` Marc Zyngier

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=28f9c1cd-e1df-f4db-32b4-c9ca0f0f256a@ti.com \
    --to=lokeshvutla@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=nm@ti.com \
    --cc=punit.agrawal@arm.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.