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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <482392C4.7080901@zytor.com>
Date:	Thu, 08 May 2008 16:54:44 -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:
> On Thu, May 08, 2008 at 02:59:31PM -0700, Venkatesh Pallipadi wrote:
>>>
>> I agree we need a better range check in place. But, the current one was not
>> really doing anything useful and actually causing the side-effect
>> regression. So, I felt not having it is better solution for now.
>>
>> Other solution is to stay with start and end range check and just ignore the
>> range check error with WC overlap in case where UC_MINUS is requested.
>>
>> Given the way MTRRs are defined, the only way to do the full range check
>> seems to be to go over page by page (from start to end), and check which
>> variable range MTTR it matches with, which is obviously very excessive. As,
>> this is not a problem in typical usage scenario.
>>

I don't believe that is true in the slightest.  You can iterate over the 
variable MTRRs and see if any part of them overlaps the target range; 
doing exhaustive enumeration is clearly bogus, especially on 64-bit 
platforms.

> 
> Also, note that we only look for start while looking at fixed range MTRRs.
> This is not as scary as it seems. We are finding the effective memory type
> by just looking at the start of the address range. We still go through
> the PAT reserve free mechanism, once we find the effective memory type
> and that list will catch any other users with conflicting type anywhere
> in the start to end range. And we will still keep effective type consistent
> across all mappings.
> 

So what you're saying here is "it's bogus, but it doesn't really matter 
anyway?"  Why bother having it at all, then?

Seriously, if it's not unconditionally correct, then:

a. it should be *clearly* labelled a heuristic.
b. it should be *clearly* explained why having the heuristic is much 
better than not having anything.

In this case, neither of those conditions appear to be addressed.

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