[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.1010111842130.2764@xanadu.home>
Date: Mon, 11 Oct 2010 18:53:43 -0400 (EDT)
From: Nicolas Pitre <nico@...xnic.net>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Felipe Contreras <felipe.contreras@...il.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
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 Mon, 11 Oct 2010, Catalin Marinas wrote:
> It may be just theoretical but architecture licensees implement the
> hardware according to the ARM ARM. If it says "unpredictable", they
> don't need to care much about this scenario as it is not allowed in
> software and the hardware can be further optimised (well, I think
> "unpredictable" doesn't allow hardware deadlocking or security
> implications, so the memory corruption cannot be that random, possibly
> just restricted to that memory range). It is probably ok on current
> hardware but I cannot guarantee, you would have to check on a
> case-by-case basis (CPU implementation).
I've seen real designs where "security implications" was interpreted
rather liberally by the hardware people, and not exactly in the same way
as software people do.
Nicolas
--
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