linux-kernel - Re: [PATCH] x86, microcode: Add local mutex to not hit a deadlock.

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: <20130508184117.GC11906@phenom.dumpdata.com>
Date:	Wed, 8 May 2013 14:41:17 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org, hpa@...or.com,
	mingo@...hat.com, fenghua.yu@...el.com, tglx@...utronix.de,
	xen-devel@...ts.xensource.com, stable@...r.kernel.org
Subject: Re: [PATCH] x86, microcode: Add local mutex to not hit a deadlock.

On Wed, May 08, 2013 at 08:22:35PM +0200, Borislav Petkov wrote:
> On Wed, May 08, 2013 at 12:13:03PM -0400, Konrad Rzeszutek Wilk wrote:
> > This can easily be triggered if a new CPU is added (via
> > ACPI hotplug mechanism) and from user-space do:
> > 
> > echo 1 > /sys/devices/system/cpu/cpu3/online
> > 
> > (or wait for UDEV to do it) on a newly appeared CPU.
> > 
> > The deadlock is that the "store_online" in drivers/base/cpu.c
> > takes the cpu_hotplug_driver_lock() lock, then calls "cpu_up".
> > "cpu_up" eventually ends up calling "save_mc_for_early"
> > which also takes the cpu_hotplug_driver_lock() lock.
> > 
> > And here is that kernel thinks of it:
> > 
> > smpboot: Stack at about ffff880075c39f44
> > smpboot: CPU3: has booted.
> > microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x25
> > 
> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 3.9.0upstream-10129-g167af0e #1 Not tainted
> > ---------------------------------------------
> > sh/2487 is trying to acquire lock:
> >  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81075512>] cpu_hotplug_driver_lock+0x12/0x20
> > 
> > but task is already holding lock:
> >  (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81075512>] cpu_hotplug_driver_lock+0x12/0x20
> > 
> > other info that might help us debug this:
> >  Possible unsafe locking scenario:
> > 
> >        CPU0
> >        ----
> >   lock(x86_cpu_hotplug_driver_mutex);
> >   lock(x86_cpu_hotplug_driver_mutex);
> > 
> >  *** DEADLOCK ***
> 
> Ok, just for my own understanding: is this something which can actually
> happen now?

Yes. Since v3.9 I've been getting this.
> 
> Judging by the presence of traces, it can be triggered in a guest,
> correct?

Correct. I don't have the hardware to test this on baremetal but looking
at how processor-driver.c works I would think this would be hit there as well.

> 
> Thanks.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/