linux-kernel - Re: [PATCH 1/1] arm64: tegra: fix PPI interrupt flag

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

Date:   Mon, 3 Apr 2017 14:11:49 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Aniruddha Banerjee <aniruddhab@...dia.com>,
        Thierry Reding <treding@...dia.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Alexander Van Brunt <avanbrunt@...dia.com>
Subject: Re: [PATCH 1/1] arm64: tegra: fix PPI interrupt flag

On 03/04/17 13:55, Jon Hunter wrote:
> Adding Marc ...
> 
> On 03/04/17 12:19, Aniruddha Banerjee wrote:
>> The interrupt flag for PPI should not be set to any value, since the
>> register is read-only. Fix the flags for the PPI interrupts to
>> IRQ_TYPE_NONE, so that there is no write to the read-only register.
> 
> If the below matches the h/w default, does this really cause a problem?
> 
> Note, we will not attempt to write the type if it matches the current
> programmed type.
> 
> I had thought that the in DT file, the type for the PPI should align
> with the h/w default in the case where it cannot be written. However, I
> guess this is not explicitly stated anywhere I have found, but at the
> same time the binding doc for the arm,gic.txt does not list
> "IRQ_TYPE_NONE" as an option.
> 
> Marc, what are your thoughts?

My immediate answer is "Why?".

As you pointed out, we don't even try to program the GICD_ICFGR1
register if what we read from it is the right thing. Also, the GICv2
spec says in 4.3.13: "For PPIs, it is IMPLEMENTATION DEFINED whether the
most significant bit of the Int_config field is programmable.".

So NONE is always wrong (because there is no such thing in the HW), and
the DT should have a setting that matches the HW even GICD_ICFGR1 is RO
(the OS may need to know how the triggering configuration anyhow).

Aniruddha: what problem are you trying to solve here? The DT you're
touching seems just fine to me...

Thanks,

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