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

Message-ID: <1aa42fe27092cd25a81b13030048510a@www.loen.fr>
Date:   Fri, 06 Dec 2019 08:54:27 +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

On 2019-12-06 08:44, Gaurav Kohli wrote:
> On 12/5/2019 6:48 PM, Marc Zyngier wrote:
>> On 2019-12-05 13:01, Gaurav Kohli wrote:
>>> On 12/5/2019 6:17 PM, Marc Zyngier wrote:
>>>> 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?
>>>>
>>>
>>> Yes RDs only.
>>>>> 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.
>>> Yes, suppose gic is configured for 8 cpus but soc has only 4 cpus.
>>> Then in this case gic_iterate will iterate till it get TYPER_LAST.
>> And that's what is expected from the architecture.
>>
>>>
>>> But as gic is configured for 8, So last bit sets in eight
>>> redistributor regions only.
>>>> - 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.
>>>
>>> There are 4 cpus present, that's why we have mapped 4 redistributor
>>> only, but during probe below function keeps iterating and give mem
>>> abort for 5th cpu.
>>>
>>> static void gic_update_vlpi_properties(void)
>>> {
>>>         gic_iterate_rdists(__gic_update_vlpi_properties);
>>>
>>> }
>>>
>>> We can solve this problem by mapping all eight redistributor in dt,
>>> but ideally code should also able to handle this and we can avoid
>>> mappin?
>> The whole point of DT is to describe the HW, all the HW, nothing but
>> the HW. This is what is expected by both the architecture and Linux.
>> So you have the solution already. Don't lie to the kernel, and 
>> everything
>> will be fine.
>>         M.
>
> HI Marc,
>
> Thanks for detailed explanation, Yes we have mapped all 8
> distributors now to resolve.
> But my main concern is that last 4 redistributor is not connected to
> core, as core is not present.
> And as per gic driver it seems we are only
> iterating and populating per cpu rd pointer.
>
> So that would be fine correct, seems nothing wrong in this kind of
> configuration?

There is nothing wrong with having more redistributors that CPUs,
and that's what is anticipated by the architecture. This is also
why the GIC driver works by having each CPU finding its own
redistributor in the RD regions, rather than the other way around.

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