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]
Date:	Mon, 3 Aug 2009 11:18:42 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dave Airlie <airlied@...ux.ie>
Cc:	Thomas Hellstrom <thellstrom@...are.com>,
	Arjan van de Ven <arjan@...radead.org>,
	suresh.b.siddha@...el.com, hpa@...or.com,
	linux-kernel@...r.kernel.org, venkatesh.pallipadi@...el.com,
	tglx@...utronix.de, dri-devel@...ts.sourceforge.net
Subject: Re: [PATCH] x86: Fix CPA memtype reserving in the set_pages_array
	cases


* Dave Airlie <airlied@...ux.ie> wrote:

> > hm, i'm missing a description about how this bug was triggered. 
> > How did you end up getting highmem pages to a cpa call?
> 
> GEM and TTM both allocate page arrays and just pass them to cpa, 
> we don't know what type of pages the allocator gives us back and 
> we really shouldn't have to, so having cpa ignore highmem pages is 
> certainly the right option.
> 
> GEM just uses shmem code to alloc the pages and TTM has its own 
> allocator.

Neither of my questions was answered though: do highmem pages ever 
get passed in and what were the effects of the bug and how was it 
noticed?

If no highmem pages can be passed in then the right solution is not 
to ignore them silently but to add a WARN_ONCE() to enforce that 
they are not used in the future either.

If they are used today then i'd like to know where exactly and 
double check that all the cache attributes are consistent: as a 
highmem page might be visible to user-space as well or might be 
mapped via the vmalloc space, etc.

And yes, if it happens and all the other mapping aliases are fine 
then ignoring them is the right solution.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ