linux-kernel - Re: [PATCH] x86: let 32bit use apic

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: <Pine.LNX.4.55.0807141805500.16334@cliff.in.clinika.pl>
Date:	Mon, 14 Jul 2008 18:20:26 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Cyrill Gorcunov <gorcunov@...il.com>
cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: let 32bit use apic_ops too

On Mon, 14 Jul 2008, Cyrill Gorcunov wrote:

> Maciej, but if we eliminate LOCK# by using simple MOV there will not
> be guarantee for atomicity. Am I wrong?

 You are right, but we do not care about atomicity.  We only care about
interrupts.  This is because the local APIC is private to its associated
CPU and inaccessible from the outside, at least for writes (mind the
Remote Read command), so as long as the local CPU does not issue
consecutive write cycles, there is no problem with another CPU getting in
the way.  Which means any RMW instruction would suffice here, with the R
part of the cycle separating any possible preceding write from one
immediately following, but unfortunately the only one we can use is the
XCHG and it has always implied the LOCK#, since the 8086, which at that
point was considered a microoptimization (the LOCK# was cheap and an extra
memory byte, otherwise needed for the LOCK prefix, expensive back then).  
So atomicity is an unfortunate side effect rather than a part of the
design here.

 Now if we know the APIC does not suffer from the double-write erratum,
then we can use a straight MOV as consecutive writes are not a concern
anymore.

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