linux-kernel - Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash

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:   Fri, 9 Mar 2018 11:33:55 +0100
From:   Grzegorz Jaszczyk <jaz@...ihalf.com>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     Mark Rutland <mark.rutland@....com>, catalin.marinas@....com,
        will.deacon@....com, james.morse@....com,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Hoeun Ryu <hoeun.ryu@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Nadav Haklai <nadavh@...vell.com>,
        Marcin Wojtas <mw@...ihalf.com>
Subject: Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash_shutdown

> Not using EOImode==1 is definitely an oddity (at least on the host), but
> that doesn't mean it shouldn't work.
>
> The reason the thing is hanging is that although we correctly deactivate
> the interrupt, nothing performs the priority drop. Your write to EOI
> helps in the sense that it guarantees that both priority drop and
> deactivate are done with the same operation, but that's not something
> we'd want to expose.
>
> My preferred approach would be to nuke the active priority registers at
> boot time, as the CPUs come up. I'll try to write something this week.

I've made a PoC which performs priority drop at boot time as you
suggested and it works with both GICv2 and GICv3 but I see some
problem:
It seems that the only way to drop the priority is to perform write to
EOI register (the GIC_RPR is RO). According to GIC documentation a
write to EOI register must correspond to the most recent valid read
from IAR. The problem is that the interrupt was already acked in the
'original' kernel, so reading GICC_IAR in crashdump kernel returns
spurious interrupt and it seems that there is no way to figure out
appropriate irqnr for EOI write. Nevertheless I've observed that
choosing random irqnr for EOI write works fine (maybe because all
interrupts in Linux uses the same priority?).

Here is the PoC (not ready for submission only for further
discussion): https://pastebin.com/gLYNuRiZ

Looking forward to your feedback.

Thank you in advance,
Grzegorz