linux-kernel - Re: Query about IPI as NMI (pseudo-NMI) support patches

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, 4 Jan 2023 21:19:12 +0530
From:   Mukesh Ojha <quic_mojha@...cinc.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     lkml <linux-kernel@...r.kernel.org>
Subject: Re: Query about IPI as NMI (pseudo-NMI) support patches

Hi Marc,

Thanks for your patience in replying queries

On 1/3/2023 11:15 PM, Marc Zyngier wrote:
> On Tue, 03 Jan 2023 16:45:04 +0000,
> Mukesh Ojha <quic_mojha@...cinc.com> wrote:
>>
>> Hi,
>>
>> Thanks for your reply.
>>
>> On 1/2/2023 10:41 PM, Marc Zyngier wrote:
>>> Hi Mukesh,
>>>
>>> On Mon, 02 Jan 2023 16:44:59 +0000,
>>> Mukesh Ojha <quic_mojha@...cinc.com> wrote:
>>>>
>>>> Hi Marc,
>>>>
>>>> I was looking similar support mentioned in below patch series.
>>>>
>>>> https://lore.kernel.org/lkml/CAFA6WYO0+LQ=mB1spCstt0cNZ0G+sZu_+Wrv6BKSeXqF5SRq4A@mail.gmail.com/#t
>>>>
>>>> Wanted to check if there is chance of these patches to land in
>>>> mainline ?
>>>
>>> I certainly have no intention to merge it as is, specially as there is
>>> no good usage model for it other than "but think of debug!".
>>>
>>> We have exactly *one* SGI left. If we are going to lose it over such a
>>> feature, I'd want a description of how we are going to share it
>>> between potential users, and how we claw some currently used SGIs
>>> back.
>>
>>
>> But, looks like patch will fail if SGI is not available.
>>
>> https://lore.kernel.org/lkml/1604317487-14543-4-git-send-email-sumit.garg@linaro.org/
>>
>>
>>
>> set_smp_ipi_range(base_sgi, 8);
>>
>> +	if (n > nr_ipi)
>> +		set_smp_dynamic_ipi(ipi_base + nr_ipi);
>> +
>>
>> So, static SGI allocation still has higher priority than dynamic
>> one.  Would you be accepting if we keep it under some
>> CONFIG_ARM64_IPI_NMI_DEBUG ?
> 
> But why should this thing have priority over other potential features?
> As I said above, there are two requirements:
> 
> - being able to share a single NMI SGI amongst multiple users
> 
> - being able to free existing SGIs in case we absolutely need an SGI
>    for some other purposes
> 
> In both cases, this is about making the SGI space scale *beyond* the 8
> possible interrupts that we have. This needs to be solved to get
> something like this in.

Agree, we have shortage of SGI's, Will try to think if we can fix this.

However, I think IPI_CPU_STOP is something which can be used as an NMI, 
As this will be used only(once) during panic()->send_smp_stop().

Can we do some special handling for IPI_CPU_STOP similar to pmu 
interrupts like request it as NMI and fallback to normal irq if not 
supported/on error ?


> 
> And I don't think hiding this behind an obscure "debug" configuration
> option that will get abused with out of tree stuff is a good move.
> Quite the opposite.
> 

Thanks, Make sense.

> Thanks,
> 
> 	M.
> 

-Mukesh