linux-hardening - Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send

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: <ZeH81_k6TFk7W4tm@FVFF77S0Q05N>
Date: Fri, 1 Mar 2024 16:05:52 +0000
From: Mark Rutland <mark.rutland@....com>
To: Doug Anderson <dianders@...omium.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Misono Tomohiro <misono.tomohiro@...itsu.com>,
	Chen-Yu Tsai <wens@...e.org>, Stephen Boyd <swboyd@...omium.org>,
	Daniel Thompson <daniel.thompson@...aro.org>,
	Sumit Garg <sumit.garg@...aro.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tony Luck <tony.luck@...el.com>,
	Valentin Schneider <vschneid@...hat.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: smp: smp_send_stop() and crash_smp_send_stop()
 should try non-NMI first

Hi Doug,

On Tue, Feb 27, 2024 at 04:57:31PM -0800, Doug Anderson wrote:
> On Mon, Jan 8, 2024 at 4:54 PM Doug Anderson <dianders@...omium.org> wrote:
> > On Thu, Dec 7, 2023 at 5:03 PM Douglas Anderson <dianders@...omium.org> wrote:

> > The sound of crickets is overwhelming. ;-) Does anyone have any
> > comments here? Is this a terrible idea? Is this the best idea you've
> > heard all year (it's only been 8 days, so maybe)? Is this great but
> > the implementation is lacking (at best)? Do you hate that this waits
> > for 1 second and wish it waited for 1 ms? 10 ms? 100 ms? 8192 ms?
> >
> > Aside from the weirdness of a processor being killed while holding the
> > console lock, it does seem beneficial to give IRQs at least a little
> > time to finish before killing a processor. I don't have any other
> > explicit examples, but I could just imagine that things might be a
> > little more orderly in such a case...
> 
> I'm still hoping to get some sort of feedback here. If people think
> this is a terrible idea then I'll shut up now and leave well enough
> alone, but it would be nice to actively decide and get the patch out
> of limbo.
> 
> FWIW the serial console dumping issue that originally inspired me to
> track this down has been worked around at least well enough to not
> spew garbage in my console. See commit 9e957a155005 ("serial:
> qcom-geni: Don't cancel/abort if we can't get the port lock"). It's
> still a little awkward because we'll be running fully lockless during
> panic time, but it seems to work...

This is on my list of things to look into, but I haven't had the chance to go
through it in detail.

>From a high level, I think this sounds reasonable; I just want to make sure
this doesn't lead to any new surprises...

Mark.