linux-kernel - Re: [PATCH V2] ACPI / APEI: restore interrupt before panic in sdei flow

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]

Message-ID: <ddefdfea-a8ca-8735-0f81-8b2748587da5@arm.com>
Date:   Mon, 18 Oct 2021 18:21:29 +0100
From:   James Morse <james.morse@....com>
To:     乱石 <zhangliguang@...ux.alibaba.com>
Cc:     linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Tony Luck <tony.luck@...el.com>,
        linux-arm-kernel@...ts.infradead.org,
        Borislav Petkov <bp@...en8.de>, Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        huangming@...ux.alibaba.com
Subject: Re: [PATCH V2] ACPI / APEI: restore interrupt before panic in sdei
 flow

Hi Liguang,

On 14/10/2021 15:18, 乱石 wrote:
> 在 2021/10/14 1:44, James Morse 写道:
>> On 12/10/2021 15:29, Liguang Zhang wrote:
>>> When hest acpi table configure Hardware Error Notification type as
>>> Software Delegated Exception(0x0B) for RAS event, OS RAS interacts with
>>> ATF by SDEI mechanism. On the firmware first system, OS was notified by
>>> ATF sdei call.

>>> If fatal RAS error occured, panic was called in sdei_asm_handle()
>>> without ehf_deactivate_priority executed, which lead interrupt masked.

>> So far the story is:
>> Firmware generated and SDEI event (a kind of software NMI) because of a firmware
>> interrupt, but it hasn't completely handled the interrupt.
>>
>>
>>> If interrupt masked, system would be halted in kdump flow like this:
>>>
>>> arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq
>>> arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq
>>> arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq
>>> arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting...

>> How and why do firmware interrupts affect the IOMMU?

[...]

>> Could you debug why firmware interrupts being active prevent the SMMU from being reset. As
>> far as I can tell, those should be totally independent.

> If ehf_deactivate_priority() was not executed, pmr_el1 register was not resumed to >0x80,
> which leads
> non-secure interrupts masked. arm_smmu_device_probe() finally called usleep_range() which
> based on
> hrtimer. Because non-secure timer interrupts was masked, usleep_range would not reponse.

Aha! So nothing to do with with the SMMU at all.

Your firmware has 'disabled' the interrupt by moving the CPUs priority mask so that no
interrupts at all can be taken.

I still think this is best fixed in firmware.

Papering over the problem here is not enough as the handler may encounter memory
corruption, take an exception, and panic() from some other part of the kernel. Its RAS -
we know something has gone wrong before we get to this point.

The OS needs to be able to call panic() at any point in time.


Your firmware should not deny the normal-world interrupts like this.
Please either complete the interrupt handling before calling into the normal world,
or disable it if you need the interrupt to not fire again. If the device that triggers the
interrupt doesn't have a disable, there are hardware registers in the GIC to do this.
(I don't know how TFA works here, it may be a bug in the upstream code)



Thanks,

James