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]

Message-ID: <20080811190908.GM13158@linux-os.sc.intel.com>
Date:	Mon, 11 Aug 2008 12:09:08 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Nick Piggin <npiggin@...e.de>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [rfc][patch] x86: avoid highmem cache attribute aliasing

On Mon, Aug 11, 2008 at 10:10:19AM -0700, Ingo Molnar wrote:
> 
> * 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?

Andi pointed out in another thread that we don't use GFP_HIGHMEM in the
AGP drivers. And hence we haven't encountered an issue so far. But yes,
this is a good fix to close the hole.

thanks,
suresh
--
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/