linux-kernel - Re: [PATCH -tip] x86,apic: Use PAGE

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:	Tue, 10 Nov 2009 00:15:36 +0000 (GMT)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Cyrill Gorcunov <gorcunov@...nvz.org>, Ingo Molnar <mingo@...e.hu>,
	Yinghai Lu <yinghai@...nel.org>, x86team <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip] x86,apic: Use PAGE_SIZE instead of numbers

On Mon, 9 Nov 2009, H. Peter Anvin wrote:

> In theory we could have more than one ioapic packed into a single page,
> and it is also entirely plausible we'll support other page sizes in x86
> at some point.  However, it's probably easier to flag something as
> PAGE_SIZE and have to fix it up later than have magic constants, so I
> think it's probably the right thing to do.

 Hmm, the MPS said in Chapter 3.6.5 "APIC Memory Mapping":

 "Non-default APIC base addresses can be used if the MP configuration 
table is provided. (Refer to Chapter 4.)  However, the local APIC base 
address must be aligned on a 4K boundary, and the I/O APIC base address 
must be aligned on a 1K boundary."

This probably still stands; I suppose it would be safer to define 
IOAPIC_SLOT_SIZE to 1024 and use it by default, expanding all reservations 
as needed where less than PAGE_SIZE / IOAPIC_SLOT_SIZE I/O APICs would be 
mapped in a page.  This is relatively recent a piece of code -- how much 
has it been tested?

 Well, actually not much as a quick search has revealed this message:

http://marc.info/?l=linux-kernel&m=118114792006520

which shows page alignment of I/O APICs clearly does not stand, and 
moreover there are two pairs of I/O APIC in the system reported which 
share a page each.  In this case the ranges requested do not make sense 
and some resource insertions will silently fail.  And also while page 
aliases created in fixmaps here should not harm, they make me feel a 
little bit chilly...

 Overall this piece of code needs an overhaul, fixing resource allocation 
and reusing fixmaps where possible.

  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/