linux-kernel - Re: Breakage caused by unreviewed patch in x86 tree

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]

Date:	Sun, 27 Apr 2008 15:31:49 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Breakage caused by unreviewed patch in x86 tree

James Bottomley wrote:
>>> Yes, that's the one ... but I believe a class of the xAPICs also used a
>>> similar principle.
>> I certainly have never seen a system on which the APIC has been mapped 
>> cacheable.  I would be very interested in the details, so if you could 
>> elaborate that would be extremely useful.
> 
> Not really ... I just remember when the SAPIC and later the xAPIC
> details were published as novel nearly a decade ago, I remember saying
> that some of the voyager interrupt controllers had been using a similar
> method for years.
> 

Well, I just looked up the xAPIC spec, and it states very clearly:

APIC registers are memory-mapped to a 4-KByte region of the processor’s 
physical address space with an initial starting address of FEE00000H. 
For correct APIC operation, this address space must be mapped to an area 
of memory that has been designated as strong uncacheable (UC). See 
Section 10.3, “Methods of Caching Available.”

So any use of cacheline-related bus cycles is generated by the LAPIC and 
doesn't affect the CPU <-> LAPIC interface.

	-hpa

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