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
| ||
|
Message-ID: <8e30b99e-70ed-7d5a-ea1f-3b0fadb644bc@igalia.com> Date: Mon, 17 Oct 2022 11:00:46 -0300 From: "Guilherme G. Piccoli" <gpiccoli@...lia.com> To: Russell King <linux@...linux.org.uk>, Marc Zyngier <maz@...nel.org>, linux-arm-kernel@...ts.infradead.org, will@...nel.org, Mark Rutland <mark.rutland@....com>, arnd@...db.de, Catalin Marinas <catalin.marinas@....com> Cc: kexec@...ts.infradead.org, pmladek@...e.com, bhe@...hat.com, akpm@...ux-foundation.org, linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org, netdev@...r.kernel.org, x86@...nel.org, kernel-dev@...lia.com, kernel@...ccoli.net, halves@...onical.com, fabiomirmar@...il.com, alejandro.j.jimenez@...cle.com, andriy.shevchenko@...ux.intel.com, bp@...en8.de, corbet@....net, d.hatayama@...fujitsu.com, dave.hansen@...ux.intel.com, dyoung@...hat.com, feng.tang@...el.com, gregkh@...uxfoundation.org, mikelley@...rosoft.com, hidehiro.kawai.ez@...achi.com, jgross@...e.com, john.ogness@...utronix.de, keescook@...omium.org, luto@...nel.org, mhiramat@...nel.org, mingo@...hat.com, paulmck@...nel.org, peterz@...radead.org, rostedt@...dmis.org, senozhatsky@...omium.org, stern@...land.harvard.edu, tglx@...utronix.de, vgoyal@...hat.com, vkuznets@...hat.com, xuqiang36@...wei.com Subject: Re: [PATCH V3 01/11] ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths On 18/09/2022 10:58, Guilherme G. Piccoli wrote: > On 19/08/2022 19:17, Guilherme G. Piccoli wrote: >> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs >> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which >> is responsible for that. IRQs are architecturally masked when we >> take an interrupt, but FIQs are high priority than IRQs, hence they >> aren't masked. With that said, it makes sense to disable FIQs here, >> but there's no need for (re-)disabling IRQs. >> >> More than that: there is an alternative path for disabling CPUs, >> in the form of function crash_smp_send_stop(), which is used for >> kexec/panic path. This function relies on a SMP call that also >> triggers a busy-wait loop [at machine_crash_nonpanic_core()], but >> without disabling FIQs. This might lead to odd scenarios, like >> early interrupts in the boot of kexec'd kernel or even interrupts >> in secondary "disabled" CPUs while the main one still works in the >> panic path and assumes all secondary CPUs are (really!) off. >> >> So, let's disable FIQs in both paths and *not* disable IRQs a second >> time, since they are already masked in both paths by the architecture. >> This way, we keep both CPU quiesce paths consistent and safe. >> >> Cc: Marc Zyngier <maz@...nel.org> >> Cc: Michael Kelley <mikelley@...rosoft.com> >> Cc: Russell King <linux@...linux.org.uk> >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@...lia.com> >> Monthly ping - let me know if there's something I should improve in order this fix is considered! Thanks, Guilherme
Powered by blists - more mailing lists