linux-kernel - Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator

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] [day] [month] [year] [list]

Date:	Mon, 26 Sep 2011 14:00:14 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Daniel Walker <dwalker@...eaurora.org>,
	Jonathan Corbet <corbet@....net>, Mel Gorman <mel@....ul.ie>,
	Chunsang Jeong <chunsang.jeong@...aro.org>,
	Jesse Barker <jesse.barker@...aro.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org,
	Michal Nazarewicz <mina86@...a86.com>,
	linaro-mm-sig@...ts.linaro.org, linux-mm@...ck.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Ankita Garg <ankita@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	ksummit-2011-discuss@...ts.linux-foundation.org,
	linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org
Subject: Re: [PATCH 6/8] drivers: add Contiguous Memory Allocator

On Wed, Aug 03, 2011 at 12:43:50PM -0500, James Bottomley wrote:
> I assume from the above that ARM has a hardware page walker?

Correct, and speculative prefetch (which isn't prevented by not having
TLB entries), so you can't keep entries out of the TLB.  If it's in
the page tables it can end up in the TLB.

The problem is that we could end up with conflicting attributes available
to the hardware for the same physical page, and it is _completely_
undefined how hardware behaves with that (except that it does not halt -
and there's no exception path for the condition because there's no
detection of the problem case.)

So, if you had one mapping which was fully cacheable and another mapping
which wasn't, you can flush the TLB all you like - it could be possible
that you still up with an access through the non-cacheable mapping being
cached (either hitting speculatively prefetched cache lines via the
cacheable mapping, or the cacheable attributes being applied to the
non-cacheable mapping - or conversely uncacheable attributes applied to
the cacheable mapping.)

Essentially, the condition is labelled 'unpredictable' in the TRMs,
which basically means that not even observed behaviour can be relied
upon, because there may be cases where the observed behaviour fails.
--
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/