linux-kernel - Re: [rfc][patch] x86: avoid highmem cache attribute aliasing

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:	Mon, 11 Aug 2008 19:10:19 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Nick Piggin <npiggin@...e.de>
Cc:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>, tglx@...utronix.de,
	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [rfc][patch] x86: avoid highmem cache attribute aliasing


* Nick Piggin <npiggin@...e.de> wrote:

> Highmem code can leave ptes and tlb entries around for a given page 
> even after kunmap, and after it has been freed.
> 
> From what I can gather, the PAT code may change the cache attributes 
> of arbitrary physical addresses (ie. including highmem pages), which 
> would result in aliases in the case that it operates on one of these 
> lazy tlb highmem pages.
> 
> Flushing kmaps should solve the problem.
> 
> I've also just added code for conditional flushing if we haven't got 
> any dangling highmem aliases -- this should help performance if we 
> change page attributes frequently or systems that aren't using much 
> highmem pages (eg. if < 4G RAM). Should be turned into 2 patches, but 
> just for RFC...

hm, such aliasing might happen in theory - and i guess in practice too 
if the AGP driver allocates/deallocates aperture in short succession. 

Maybe this could corrupt the X framebuffer - or even generic kernel RAM. 
Mind resending the two split up patches? The fix we might want to take 
into v2.6.27, the speedup probably for v2.6.28.

But maybe i'm missing something obvious that prevents such problems on 
32-bit systems - Venki, Suresh, what do you think?

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