linux-kernel - Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug

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: <48A388CE.2020404@goop.org>
Date:	Wed, 13 Aug 2008 18:22:22 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Steven Rostedt <srostedt@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Roland McGrath <roland@...hat.com>,
	Ulrich Drepper <drepper@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
	Clark Williams <williams@...hat.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with	preemptible
 kernel and CPU hotplug

H. Peter Anvin wrote:
> I believe this should be okay.  In 32-bit mode some of the security 
> and hypervisor frameworks want to set segment limits, but I don't 
> believe they ever would set DS and SS inconsistently, or that we'd 
> handle a #GP versus an #SS differently (segment violations on the 
> stack segment are #SS, not #GP.)  To be 100% sure we'd have to pick 
> apart the modr/m byte to figure out what the base register is but I 
> think that's total overkill.

The kernel sets ds and ss to the same selector, so they're always going 
to have the same underlying descriptor.

My only concern is whether there are any locked instructions which are 
explicitly using a cs: override for those odd corners of the kernel.  I 
don't think so.

That said, I wonder how useful it is to do the SMP->UP code transition.  
How often does a kernel go from being SMP to UP in a situation where we 
really care about the performance?  And that won't be shortly be 
becoming SMP again anyway?

    J
--
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/