linux-kernel - Re: Query on handling some special Group0 interrupt in Linux

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]

Message-ID: <8d6f41f6-96ae-2f34-4bc7-58b63bf55159@quicinc.com>
Date:   Thu, 10 Nov 2022 01:27:24 +0530
From:   Mukesh Ojha <quic_mojha@...cinc.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     <linux-arm-kernel@...ts.infradead.org>, <catalin.marinas@....com>,
        <will@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Query on handling some special Group0 interrupt in Linux

Hi Marc,

Thanks for your reply.

On 11/9/2022 11:50 PM, Marc Zyngier wrote:
> On Wed, 09 Nov 2022 16:20:35 +0000,
> Mukesh Ojha <quic_mojha@...cinc.com> wrote:
>>
>> Hi,
>>
>> I was working on a use case where both el2/el3 are implemented and we
>> have a watchdog interrupt (SPI), which is used for detecting software
>> hangs and cause device reset; If that interrupt's current cpu affinity
>> is on a core, where interrupts are disabled, we won't be able to serve
>> it or if this interrupt comes on a core which has interrupt enabled,
>> calling panic() or with smp_send_stop(), we would not be able
>> to know the call stack of the other cores which is running with
>> interrupt disabled.
>>
>> I was thinking of configuring both a watchdog irq(SPI) and IPI_STOP
>> (SGI) or any reserve IPI as an FIQ. And from the watchdog irq handler,
>> I was thinking of calling panic() which eventually sends IPI_STOP(SGI
>> FIQ) to all the cores. And with this we will able to dump all the core
>> call stack.
>>
>> I am able to achieve this but wanted to know if this is acceptable to
>> the community to support/allow such use cases like above and enable
>> group0 interrupt from GIC for some special use cases.
> 
> For a start, we only deal with Group-1 interrupts in Linux. Group-0
> interrupts are for the firmware, and we really don't want to see them
> (this is consistent with your HW having EL3). 

What is the downside of it we support this ? I see one of the 
implementation here.

https://elixir.bootlin.com/linux/v6.0.7/source/drivers/irqchip/irq-apple-aic.c#L510

>We also mask IRQ and FIQ at the same time, so this is a non-starter.
This can be taken care if we support this.

> 
> If you want to be able to deliver an interrupt while the interrupts
> are masked, what you are looking for is the NMI framework, for which
> you can register SPIs as (pseudo-)NMI.

Yes, kind of NMI.
I have already looked into this.
Since, in our system El2 is implemented and each physical interrupt get 
routed to hypervisor and later vIrq comes to El1 and each interrupt 
enable/disable call exercise pmr register trap can cause latency in
regular run(like multiple VM).

Since, some of the use-case could be special like i have mentioned
in my initial mail where such interrupt will be fatal and system will
get reset after that. I am not able to think of any other use case than
this but can this not be considered as one of the feature.

> 
> This is of course assuming that you're using GICv3. If you're using an
> older version of the architecture, we don't have a good solution for
> you, unfortunately.
> 

we are using GICv3.

> Thanks,
> 
> 	M.
> 

-Mukesh