linux-kernel - Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

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: <1287196588.2370.1.camel@pasglop>
Date:	Sat, 16 Oct 2010 13:36:28 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	Arnd Hannemann <arnd@...dnet.de>,
	Hemant Pedanekar <hemantp@...com>, Greg KH <greg@...ah.com>,
	linux-main <linux-kernel@...r.kernel.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Han Jonghun <jonghun79.han@...il.com>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

On Fri, 2010-10-08 at 18:53 +0100, Russell King - ARM Linux wrote:
> As already discussed, it's nigh on impossible to unmap the existing
> direct mapped region (read the previous discussions about why this is)
> - which is precisely why there is no direct alternative solution.
> 
> The only possible solution is to exclude some memory at boot time from
> the system direct map so that it never appears in the direct map, and
> use ioremap on _that_.  Another possible alternative is to use
> highmem,
> obtain highmem pages (making sure that it doesn't fall back to lowmem)
> and remap them using interfaces such as vmap.
> 
> So there are solutions to the problem, but it seems that _no one_ is
> willing to discuss it other than "we want our old way back".
> 
> If you want the old way back, apply pressure to silicon vendors and
> ARM Ltd to change the architecture to lift this restriction - which
> will probably mean doing away with aggressive speculative prefetching
> so that it's possible to predict what will be in the cache at any
> point in time. 

Note that we have the exact same problem on powerpc. The only sane
solution is that SoCs designed around such cores or versions of the
architecture should be fully DMA coherent to avoid the need for funky
mapping attributes. Anything else is garbage HW, but sadly, it looks
like way too many idiots still find jobs as HW designers.

Cheers,
Ben.


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