linux-hardening - Re: [PATCH v2] 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: <CAD=FV=VodEuhwaTh5ne0YCPkvxna0rkL9_mKN2tJzhWL3ToVEw@mail.gmail.com>
Date: Mon, 5 Aug 2024 13:21:30 -0700
From: Doug Anderson <dianders@...omium.org>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Will Deacon <will@...nel.org>, Catalin Marinas <catalin.marinas@....com>, 
	Mark Rutland <mark.rutland@....com>, Sumit Garg <sumit.garg@...aro.org>, 
	Misono Tomohiro <misono.tomohiro@...itsu.com>, Stephen Boyd <swboyd@...omium.org>, 
	Chen-Yu Tsai <wens@...e.org>, Marc Zyngier <maz@...nel.org>, 
	Daniel Thompson <daniel.thompson@...aro.org>, 
	D Scott Phillips <scott@...amperecomputing.com>, Frederic Weisbecker <frederic@...nel.org>, 
	"Guilherme G. Piccoli" <gpiccoli@...lia.com>, James Morse <james.morse@....com>, Kees Cook <kees@...nel.org>, 
	Tony Luck <tony.luck@...el.com>, linux-arm-kernel@...ts.infradead.org, 
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm64: smp: smp_send_stop() and crash_smp_send_stop()
 should try non-NMI first

Hi,

On Mon, Aug 5, 2024 at 10:26 AM Yu Zhao <yuzhao@...gle.com> wrote:
>
> > > > +     /*
> > > > +      * Start with a normal IPI and wait up to one second for other CPUs to
> > > > +      * stop. We do this first because it gives other processors a chance
> > > > +      * to exit critical sections / drop locks and makes the rest of the
> > > > +      * stop process (especially console flush) more robust.
> > > > +      */
> > > > +     smp_cross_call(&mask, IPI_CPU_STOP);
> > >
> > > I realise you've moved this out of crash_smp_send_stop() and it looks
> > > like we inherited the code from x86, but do you know how this serialise
> > > against CPU hotplug operations? I've spent the last 20m looking at the
> > > code and I can't see what prevents other CPUs from coming and going
> > > while we're trying to IPI a non-atomic copy of 'cpu_online_mask'.
> >
> > I don't think there is anything. ...and it's not just this code
> > either.
>
> I agree -- I noticed this a while ago [1], and I added
> cpus_read_lock/unlock() on the caller side, because having the locks
> inside callees can be a problem for callers who can't sleep.
>
> [1] https://lore.kernel.org/linux-mm/ZnkGps-vQbiynNwP@google.com/

Sounds reasonable. I'm happy to review a patch doing that.


> Also, do the handlers always see `crash_stop` set by the sender? If
> not, would it be a problem? (In the above link, it has to do extra
> work to make sure that handlers eventually see any updated values.)

I _think_ this is OK. It's been a while since I wrote the original
patch but I seem to remember thinking that I didn't need to do
anything special. Tracing through the code again, I see in
gic_ipi_send_mask() the comment:

/*
 * Ensure that stores to Normal memory are visible to the
 * other CPUs before they observe us issuing the IPI.
 */
dmb(ishst);

...so I think that means we're fine, right?