linux-kernel - Re: [PATCH v2 1/4] genirq/irqdomain: Allow partial trimming of irq

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:   Wed, 07 Oct 2020 09:05:34 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Dmitry Osipenko <digetx@...il.com>,
        Sowjanya Komatineni <skomatineni@...dia.com>,
        Venkat Reddy Talla <vreddytalla@...dia.com>,
        kernel-team@...roid.com
Subject: Re: [PATCH v2 1/4] genirq/irqdomain: Allow partial trimming of
 irq_data hierarchy

On 2020-10-06 21:39, Thomas Gleixner wrote:
> On Tue, Oct 06 2020 at 11:11, Marc Zyngier wrote:
>> It appears that some HW is ugly enough that not all the interrupts
>> connected to a particular interrupt controller end up with the same
>> hierarchy repth (some of them are terminated early). This leaves
> 
>   depth?
> 
>> the irqchip hacker with only two choices, both equally bad:
>> 
>> - create discrete domain chains, one for each "hierarchy depth",
>>   which is very hard to maintain
>> 
>> - create fake hierarchy levels for the shallow paths, leading
>>   to all kind of problems (what are the safe hwirq values for these
>>   fake levels?)
>> 
>> Instead, let's offer the possibility to cut short a single interrupt
> 
> s/let's offer/implement/

Thanks for that, I'll fix it locally.

[...]

> This is butt ugly, really. Especially the use case where the tegra PMC
> domain removes itself from the hierarchy from .alloc()

I don't disagree at all. It is both horrible and dangerous.

My preference would have been to split the PMC domain into discrete
domains, each one having having its own depth. But that's incredibly
hard to express in DT, and would break the combination of old/new
DT and kernel.

> That said, I don't have a better idea either. Sigh...

A (very minor) improvement would be to turn the trim call in the PMC 
driver into
a flag set in the first invalid irq_data structure, and let 
__irq_domain_alloc_irqs()
do the dirty work.

Still crap, but at least would prevent some form of abuse. Thoughts?

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