linux-kernel - Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with xf86MapVidMem error

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: <48239FAC.8070707@zytor.com>
Date:	Thu, 08 May 2008 17:49:48 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
CC:	Rufus & Azrael <rufus-azrael@...ericable.fr>,
	Ingo Molnar <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	Linux-kernel Mailing List <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [2.6.25-git18 => 2.6.26-rc1-git1] Xorg crash with	xf86MapVidMem
 error

Venki Pallipadi wrote:
> 
> What I meant was:
> MTRRs are not really base and size. They are defined as base and mask.
> Any addr is affected by mtrr if addr & mask == base & mask.
> So, MTRR entry like
> base = 0xf00000, mask = 0xff00000 with 36 bit physical address covers
> 0xf00000-0xffffff, 0x10f00000-0x10ffffff, 0x20f00000-0x20ffffff, ....
> 
> In this case if user is trying to mmap 0x1a000000-0x2a000000, we cannot really
> cover this case with single parsing of variable address ranges. We will have
> to go through the sub-ranges withing single variable range, which can be page
> by page in worst case.
>  

In practice, though, such MTRRs are never seen.  Even in the presence of 
such pathological MTRRs, I'm sure one can figure out a *much* smarter 
overlap algorithm.  I'd have to sit down and think about it, but I'm 
pretty sure one could; the basic observation, though, is that any set 
mask bit that are in a position <= floor(log2(range_len))-1 don't matter 
at all, since the range WILL end up covering both the 0 and the 1 case 
in this bit position.  At this point, you can test only a limited number 
of points (I *believe* you can reduce it down to only the beginning and 
the end, but I haven't proven that, so don't count on it yet.)

The key, of course, is to look for the case of multiple MTRRs matching 
the range.

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