linux-kernel - Re: [PATCH v0] irqchip/gic-v3: Avoid check of lpi configuration for non existent cpu

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 05 Dec 2019 12:47:38 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Gaurav Kohli <gkohli@...eaurora.org>
Cc:     <tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v0] irqchip/gic-v3: Avoid check of lpi configuration for  non existent cpu

Hi Gaurav,

On 2019-12-05 10:55, Gaurav Kohli wrote:
> As per GIC specification, we can configure gic for more no of cpus
> then the available cpus in the soc, But this can cause mem abort
> while iterating lpi region for non existent cpu as we don't map

Which LPI region? We're talking about RDs, right... Or does LPI mean
something other than GIC LPIs for you?

> redistrubutor region for non-existent cpu.
>
> To avoid this issue, put one more check of valid mpidr.

Sorry, but I'm not sure I grasp your problem. Let me try and rephrase 
it:

- Your GIC is configured for (let's say) 8 CPUs, and your SoC has only 
4.

- As part of the probing, the driver iterates on the RD regions and 
explodes
   because something isn't mapped?

That'd be a grave bug, but I believe the issue is somewhere else.

>
> Signed-off-by: Gaurav Kohli <gkohli@...eaurora.org>
>
> diff --git a/drivers/irqchip/irq-gic-v3.c 
> b/drivers/irqchip/irq-gic-v3.c
> index 1edc993..adc9186 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -766,6 +766,7 @@ static int gic_iterate_rdists(int (*fn)(struct
> redist_region *, void __iomem *))
>  {
>  	int ret = -ENODEV;
>  	int i;
> +	int cpu = 0;
>
>  	for (i = 0; i < gic_data.nr_redist_regions; i++) {
>  		void __iomem *ptr = gic_data.redist_regions[i].redist_base;
> @@ -780,6 +781,7 @@ static int gic_iterate_rdists(int (*fn)(struct
> redist_region *, void __iomem *))
>  		}
>
>  		do {
> +			cpu++;
>  			typer = gic_read_typer(ptr + GICR_TYPER);
>  			ret = fn(gic_data.redist_regions + i, ptr);
>  			if (!ret)
> @@ -795,7 +797,8 @@ static int gic_iterate_rdists(int (*fn)(struct
> redist_region *, void __iomem *))
>  				if (typer & GICR_TYPER_VLPIS)
>  					ptr += SZ_64K * 2; /* Skip VLPI_base + reserved page */
>  			}
> -		} while (!(typer & GICR_TYPER_LAST));
> +		} while (!(typer & GICR_TYPER_LAST) &&
> +					cpu_logical_map(cpu) != INVALID_HWID);
>  	}
>
>  	return ret ? -ENODEV : 0;

This makes little sense. A redistributor region contains a bunch of 
RDs,
each of which maps onto a given CPU. We iterate on the RDs, and not on 
the
CPUs, as it is the RD that tells us which CPU it is affine with, not 
the
other way around.

If a RD is for some reason unavailable, then it shouldn't be described 
in
the firmware the first place. If you end-up exposing RD regions that do
not have the last RD having GICR_TYPER.Last set, then your SoC is 
broken,
and this needs yet another quirk.

         M.
-- 
Jazz is not dead. It just smells funny...