linux-kernel - Re: [PATCH 05/15] irqchip: Mask the non-type/sense bits when translating an 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:	Tue, 19 Apr 2016 15:14:07 +0100
From:	Jon Hunter <jonathanh@...dia.com>
To:	Marc Zyngier <marc.zyngier@....com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Benoît Cousson <bcousson@...libre.com>,
	Tony Lindgren <tony@...mide.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Stephen Warren" <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Kevin Hilman <khilman@...nel.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	<linux-tegra@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/15] irqchip: Mask the non-type/sense bits when
 translating an IRQ


On 09/04/16 12:03, Marc Zyngier wrote:
> On Thu, 17 Mar 2016 14:19:09 +0000
> Jon Hunter <jonathanh@...dia.com> wrote:
> 
>> The firmware parameter that contains the IRQ sense bits may also contain
>> other data. When return the IRQ type, bits outside of these sense bits
>> should be masked. If these bits are not masked and
>> irq_create_fwspec_mapping() is called to map an IRQ, then the comparison
>> of the type returned from irq_domain_translate() will never match
>> that returned by irq_get_trigger_type() (because this function masks the
>> none sense bits) and so we will always call irq_set_irq_type() to program
>> the type even if it was not really necessary.
>>
>> Currently, the downside to this is unnecessarily re-programmming the type
>> but nevertheless this should be avoided.
>>
>> The Tegra LIC, TI Crossbar and GIC-V3 irqchips all have client instances
>> (from reviewing the device-tree sources) where bits outside the IRQ sense
>> bits are set, but do not mask these bits. Therefore, ensure these bits
>> are masked for these irqchips.
> 
> For GICv3, this shouldn't be the case. The DT clearly says that the 3rd
> field should only contain the trigger description. It looks like people
> have been copying their GICv2 DT and simply slapped the v3 description
> in the middle, without changing their interrupt specifiers. Duh.

Hmmm ... I was just double checking on this for the gic-v3 by wading
through the DTS files, and may be there is no issue here. However,
looking at the current code it is a bit inconsistent between firmware
types ...

 static int gic_irq_domain_translate(struct irq_domain *d,
                                     struct irq_fwspec *fwspec,
                                     unsigned long *hwirq,
                                     unsigned int *type)
 {
         if (is_of_node(fwspec->fwnode)) {
                 if (fwspec->param_count < 3)
                         return -EINVAL;

                 switch (fwspec->param[0]) {
                 case 0:                 /* SPI */
                         *hwirq = fwspec->param[1] + 32;
                         break;
                 case 1:                 /* PPI */
                         *hwirq = fwspec->param[1] + 16;
                         break;
                 case GIC_IRQ_TYPE_LPI:  /* LPI */
                         *hwirq = fwspec->param[1];
                         break;
                 default:
                         return -EINVAL;
                 }

                 *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
                 return 0;
         }

         if (is_fwnode_irqchip(fwspec->fwnode)) {
                 if(fwspec->param_count != 2)
                         return -EINVAL;

                 *hwirq = fwspec->param[0];
                 *type = fwspec->param[1];
                 return 0;
         }

         return -EINVAL;

> I guess this patch doesn't hurt though.

Yes, it doesn't but I think I will leave this alone for now, given that
I can't find a case where this would be a problem.

Cheers
Jon